3 ms·

For Ruby.. this is probably not as bad, and some of them are probably harmless, but still. * Apartment.destroy(params[:id]) https://github.com/search?q=extens

by seivan 13y ago

For Ruby.. this is probably not as bad, and some of them are probably harmless, but still. * Apartment.destroy(params[:id]) https://github.com/search?q=extension%3Arb+path%3A%2Fapp%2Fcontrollers%2F+.destroy&type=Code&ref=searchresults https://github.com/search?q=extension%3Arb+path%3A%2Fapp%2Fc... I've found stuff like this on startups who charges people money - scary. Some of them require authentication but not authorization In other words, they require login, but not WHO you're logged in as.

Xylakant 13y ago
Your example looks much like AR and AR will sanitize the given parameter at least in this case so that's a non-issue here. Same would be true if you'd call a prepared statement in PHP and hand it a GET parameter. The problem with the given PHP samples is that they do neither: The take the unsafe user-provided parameter and use string concatenation to build a query - the textbook example of an SQL injection vulnerability.
- sdevlin 13y ago
  He's citing this as a potential cross-authorization vulnerability, not SQL injection. The form he's demonstrating is a common misstep in Rails. Instead of writing something like: current_user.apartments.destroy(params[:id]) The programmer wrote: Apartment.destroy(params[:id]) Meaning that the apartment lookup is not being done within the context of the current user, it's global. This means an attacker can delete other users' apartments with crafted URLs. When I'm testing Rails applications, I always grep the source for something like: /[A-Z][A-Za-z0-9_]\.(find|destroy|...)/ To find vulnerabilities of exactly this kind.