Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: