Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yii Framework 2.0.0 GA

yiiframework.com

Post reply on HN
Print view View original

11–20 of 55 posts

Re: Yii Framework 2.0.0 GA

#11

Post by kijin »

> Yii 2.0 helps you to write more secure code. It has built-in support to prevent SQL injections, XSS attacks ...

This is just a minor complaint, but it's so pervasive among web frameworks that I must complain yet again.

According to the documentation for Yii 2.0, the recommended way to output a variable to a web page is:
Not the PHP standard:
Because if you do the latter, you will be vulnerable to XSS.

But why does every framework (and many template engines) insist on telling you to call a specific function in the template in order to get XSS protection? HTML escaping should be turned on by default, by whatever means possible.

The simplest template syntax should also be the most secure, not the other way around. Because sooner or later, somebody is going to forget to call that function.

Auto-escaping also saves a lot of clutter in templates, since there are usually only a few places in any given page (usually the content of a post) where HTML content needs to be printed unescaped (but filtered, of course).

Some frameworks escape everything by default and only allow you to print raw HTML if you add a "noescape" flag. This is better, but some of them only do this if you turn on some sort of "autoescape" flag at the top. This is just as bad, since it is insecure by default.

One might point out that not all escaping is the same, since different escaping rules apply in different contexts. But do we really have no way to detect, when parsing and compiling a template, which context we're currently in?

XSS protection in modern template engines should be opt-out, not opt-in. Otherwise they have no right to claim XSS protection as a feature.

Re: Yii Framework 2.0.0 GA

#12

Post by krapp »

kijin wrote: post #11

> Yii 2.0 helps you to write more secure code. It has built-in support to prevent SQL injections, XSS attacks ... This is just a minor complaint, but it's so pervasive among web frameworks that I must complain yet again. According to the documentation for Yii 2.0, the recommended way to output a variable to a web page is: Not the PHP standard: Because if you do the latter, you will be vulnerable to XSS. But why does…

Twig, at least, escapes by default. Laravel's Blade templates don't, unless that's changed recently.

But the price you pay for that of course is no longer working directly in PHP but a templating language with its own syntax (for instance, array shorthand in Twig templates [] has worked since I don't know when but only recently has PHP gotten around to supporting it) which has to be parsed, and partially compiled into PHP classes.

Re: Yii Framework 2.0.0 GA

#13

Post by kijin »

krapp wrote: post #12
kijin wrote: post #11

> Yii 2.0 helps you to write more secure code. It has built-in support to prevent SQL injections, XSS attacks ... This is just a minor complaint, but it's so pervasive among web frameworks that I must complain yet again. According to the documentation for Yii 2.0, the recommended way to output a variable to a web page is: Not the PHP standard: Because if you do the latter, you will be vulnerable to XSS. But why does…

Twig, at least, escapes by default. Laravel's Blade templates don't, unless that's changed recently. But the price you pay for that of course is no longer working directly in PHP but a templating language with its own syntax (for instance, array shorthand in Twig templates [] has worked since I don't know when but only recently has PHP gotten around to supporting it) which has to be parsed, and partially compiled int…

Yeah, frameworks that use raw PHP files as views at least have that as an excuse. But the cost of using a simple template engine with good caching support seems to be minimal compared to the benefit of XSS prevention. CodeIgniter, for example, can convert short tags to full PHP tags if short tags are turned off in php.ini. They might as well wrap htmlspecialchars() around every {$var} while they're at it.

Non-PHP frameworks, on the other hand, really have no excuse.

Re: Yii Framework 2.0.0 GA

#15

Post by bigtunacan »

coldtea wrote: post #8
AlexMuir wrote: post #7

I have a lot of fondness for Yii as it introduced me to MVC and moved me from a designer into a developer. When I went on to learn Ruby and Rails everything seemed to click together and I recognised quite a lot of what Yii had taken from Rails. That said, I get the sweats when I have to wade into an old Yii-powered app that I wrote. Entirely faults of PHP (lack of symbols, array(...) declarations, semicolon-itis) and…

> Entirely faults of PHP (lack of symbols, array(...) declarations, semicolon-itis) Sorry, but those are entirely trivial syntactic issues, and not very interesting at that either...

Symbols are not a syntactic issue. They are an optimization issue. They do not have the creation overhead of objects and they exist across the application in memory without the lookup overhead of a constant (PHP's closest cousin to a symbol).

Lisp, Erlang, and Prolog (sure some other languages I've missed) have direct equivalents to Ruby symbols; they are sometimes referred to as symbols other times as atoms.

Saying they are a trivial syntactic issue just means you don't understand what symbols are.

Re: Yii Framework 2.0.0 GA

#16

Post by bigtunacan »

rdoherty wrote: post #2

Out of all the PHP frameworks I've used (CakePHP, Kohana, Laravel, Symfony) I have to say Yii is the one of the best. It's hard to describe why, I think mostly because it feels like it was built and designed by one person who had a lot of experience with other frameworks and knew PHP inside and out.

Never was a fan of Yii myself. The one PHP framework I really do like though is the Fat-Free Framework.

Re: Yii Framework 2.0.0 GA

#18

Post by lmz »

bigtunacan wrote: post #15
coldtea wrote: post #8

Earlier quoted context omitted.

> Entirely faults of PHP (lack of symbols, array(...) declarations, semicolon-itis) Sorry, but those are entirely trivial syntactic issues, and not very interesting at that either...

Symbols are not a syntactic issue. They are an optimization issue. They do not have the creation overhead of objects and they exist across the application in memory without the lookup overhead of a constant (PHP's closest cousin to a symbol). Lisp, Erlang, and Prolog (sure some other languages I've missed) have direct equivalents to Ruby symbols; they are sometimes referred to as symbols other times as atoms. Saying…

It's a bit silly to worry about the overhead of strings over symbols when the PHP environment itself is not persistent across requests.

Re: Yii Framework 2.0.0 GA

#19

Post by pestaa »

lmz wrote: post #18
bigtunacan wrote: post #15

Earlier quoted context omitted.

Symbols are not a syntactic issue. They are an optimization issue. They do not have the creation overhead of objects and they exist across the application in memory without the lookup overhead of a constant (PHP's closest cousin to a symbol). Lisp, Erlang, and Prolog (sure some other languages I've missed) have direct equivalents to Ruby symbols; they are sometimes referred to as symbols other times as atoms. Saying…

It's a bit silly to worry about the overhead of strings over symbols when the PHP environment itself is not persistent across requests.

It adds up. One request may produce millions of such strings. Ruby and especially RoR without cheap symbol lookups would be as fast as a dead fish.

Re: Yii Framework 2.0.0 GA

#20

Post by bigtunacan »

lmz wrote: post #18
bigtunacan wrote: post #15

Earlier quoted context omitted.

Symbols are not a syntactic issue. They are an optimization issue. They do not have the creation overhead of objects and they exist across the application in memory without the lookup overhead of a constant (PHP's closest cousin to a symbol). Lisp, Erlang, and Prolog (sure some other languages I've missed) have direct equivalents to Ruby symbols; they are sometimes referred to as symbols other times as atoms. Saying…

It's a bit silly to worry about the overhead of strings over symbols when the PHP environment itself is not persistent across requests.

That seems to be missing the whole point of symbols/atoms. They are uniquely identified with an O(1) lookup time and persist in memory after the initial creation. Symbols persist across multiple requests; this is a big part of why they are so beneficial.
Post reply on HN