Just made the same comment and deleted it seeing that you already stated it. Protecting against all of these is hard and no tech is going to automatically protect for all of this on its own. Such a weird statement to make that takes away from the message of the site entirely.

I worked for a company and we used the PHP ORM Propel. So in theory no SQL injections you would think, WRONG.

We used a function like findOne() (I don't recall exactly). It looked like this:

$resetTokens->findOne($GET['password-reset-token']);

The issue was that findOne would accept wildcards, so one could use ?password-reset-token=% in the URL and reset the password of any random users.

I think the webpage is talking specifically about Laravel. It ambiguously doesn't mention Laravel till later, but the code snippet looks like Laravel code. Laravel's ORM does sanitise strings.

The snippet also validates request inputs, so clearly it doesn't assume that inputs are safe.

I totally agree with everyone before me here on the issue of security.

If an app stands the stress test against say for example this comprehensive list(1), it can consider itself somewhat safe or at least benchmarked. Otherwise, only vague and unsubstantiated claims, which does not help PHP nor any other programming language or framework.

[1] https://github.com/payloadbox/xss-payload-list

In both Symfony and Laravel these days they have their own request objects to help you get information on the request. You shouldn’t be reaching into the get or post variables directly like that.

i.e. $request->query(‘password-reset-token’);

... why would you pass $GET through to a logical layer with access to a data store write without sanitizing it?

This seems like a pretty basic thing to fix, but then I only have your snippet to go by.

That’s a parametrized API that’s supposed to be safe against injection, at least to anyone who’s ever used parametrized APIs and hasn’t read the documentation of this particular library in detail. That it supports wildcard makes as much sense as log4j executing code in textual messages.

If an ORM/builder casually puts =/IS and LIKE in the same method, don’t touch it.

The code snippet is very Laravel, and it does a lot to stop all those attacks with that API.

Rails does a pretty good job.

PHP has come a long way and I have since changed my mind about Laravel but I love Ruby, and Rails does an awesome job. Laravel actually seems to try to mimick Rails in PHP

I've tried Laravel, it's a beautiful framework. But I see no reason to switch from Rails, it's a beast.

Hi!

I'm looking for advice on how Rails vs Laravel compare (as I'll have to pick one of them soon for a project). Assuming the same knowledge and familiarity on both of them, why would you prefer Rails over Laravel? Thanks!

Ruby is a beautifully-designed, concise language. PHP is the opposite. If you like Java-style verbosity you may like PHP. I don't.

Yea, I think what makes me enjoy Ruby a lot is the ability to meta-program a lot. I can mold the language to what I want to express.

Of course, this can be a double edged sword if you aren't comfortable in the language yet.

The reason why I stuck with Rails is because I am already a Ruby user. I like PHP and all but I am way more comfortable with Ruby.

I don’t think there is anything Rails can do that Laravel cannot and wise versa.

It’s about taste.

I think Rails + hotwire hit the sweetspot for me!

In general I think there’s something to be said for sticking with languages that match your model of approaching a problem. DHH gave a good, albeit a bit rambly, keynote on this topic once. He compared some of the tools selection conversations to the equivalent of people comparing gaming consoles purely by specs when in reality, picking a console mostly boiled down to what you subjectively enjoyed more. I like that idea as a rule of thumb and encourage people to start there and go with what feels right for them before making deeper choices. (Lots of nuance here, don’t want to delve too deep so please view from that context :) )

Thanks!

I think the easier way to do things is mostly always the secure way in Laravel, so unless you go out of your way to do something weird, you're mostly safe from those attacks once you know how it works under the hood (to some extent) and what Laravel does and does not do for you.

I want to second this. The top StackOverflow comment for protecting against XSS in PHP still recommends htmlspecialchars() https://stackoverflow.com/questions/1996122/how-to-prevent-x... which is a terrible and ancient approach (context-aware templates are the modern approach).

I also Googled to check CSRF protection and all the sites I can find just discuss rolling it yourself; the example uses some CSPRNG that can potentially return not cryptographically secure numbers without erroring. https://www.section.io/engineering-education/csrf-protection...

That's one thing that really drove me away from PHP. It presents an extremely simple seeming universe, in which web apps are very easy to write – but has really naïve bones, requiring a lot of extra scaffolding to be safe.

You don't get XSS protection out the box from any language's standard library, nor CSRF.

You do get XSS protection out of the box in most templating languages, though, and PHP is also a templating language.

Take this template:

  <h1>{{ title }}</h1>

In most templating languages, for a title of "<script>alert();</script>", the result will end up being:

  <h1>&lt;script&gt;alert();&lt;/script&gt;</h1>

In PHP, which is a templating language, the equivalent seems to be:

  <h1><?php echo $title; ?></h1>

But this will print the title unescaped, which is a security vulnerability, and incorrect. In reality, the equivalent is:

  <h1><?php echo htmlspecialchars($title); ?></h1>

Now, you could say, don't use PHP as a templating language! But if you're not supposed to use PHP as a templating language, why does it behave as one? This is one of PHP's footguns to be avoided. Personally, I recommend a linter like PHPCS to catch issues like this one.

Templating languages are abstractions on top of other technologies. I don't see how PHP is a templating language. I could write that exact same code above in NodeJS and I'd need to use mustache to escape the output. So you can make the same mistakes in Node, Python.

Nobody writes PHP mixing HTML and PHP anymore, and if you do you should run. Shit code is not unique to PHP and I've seen more than my life's share in JS and Python codebases.

> I don't see how PHP is a templating language [...] Nobody writes PHP mixing HTML and PHP anymore

PHP is designed to be a template language, but it's a terrible template language, so nobody (it is claimed) uses it as it was originally designed to be used anymore.

So "use PHP" is not good advice if what you mean is "use a web framework and a separate third-party template language", which works just as well in any language and doesn't give PHP any particular advantage.

Tangential, but I've always found Mustache's tagline "logic-less templates" confusing - what they mean is that the template language doesn't have control flow. Logic is not a synonym of control flow in my mind.

Well, of course not from any lang that treats HTML as a string, but there are langs, which treat HTML as structured data, in their standard libraries. Take a look at SXML libraries for example. Whatever script you stored as a username for example, it would still get treated as text, not tag, when put into lets say a span or p. SXML is aware of the boundary between tags, their attributes and their content.

I googled SXML and it appears to be have implementation libraries in lots of languages. This is not the core language's standard library.

What do you put as the distinguishing feature between "core language standard library" and "comes with the language at installation"?

Some example: https://www.gnu.org/software/guile/manual/html_node/Reading-... (no installation of anything third party required)

Alright, let's go with widely-used programming languages for now - I've been programming for over 20 years and never heard of Guile.

I am not against the idea of having native protections built into stdlib, we can agree there, but it's disingenuous to suggest that this problem is unique to PHP as the parent comment suggested. It's the same in all of the major programming languages used to spit out HTML as far as I can tell.

Oh, very much so. I don't doubt it. Most of them are doing it wrong, fiddling with strings, instead of structured data, which HTML would lend itself really nicely to. Especially PHP, with its "output HTML" in-built mentality should have gotten it right, but did not. Many others did not do any better.