4 ms·

SQL injection is not a problem of web frameworks, because SQL should never be a part of the web layer of an application in the first place.

collyw 12y ago
It shouldn't be but that's not always possible.
- mantrax3 12y ago
  It is always possible. Name one case where it isn't, and I'll tell you how it's possible :) Web frameworks should handle input (routing, request fields, url query) and output (templates). That's it.
  - collyw 12y ago
    OK, Django ORM, conditional aggregates - these were not possible last time I checked. You can do it at the application level, but say you want to keep the performance up, you need to drop into SQL.
joevandyk 12y ago
Virtually all web frameworks encourage SQL. So it is a problem. Making a private api to access the database can add a lot of needless complexity.
- mantrax3 12y ago
  That private API is called a service layer, and without it, your code devolves into copy/paste spaghetti. We live in an age when having a complementary iOS/Android app for your site is not the exception anymore. Without a service layer you'll have coupled your services with your web pages. Connecting your server with your apps will be quite painful. You don't want that. Done right, your service layers keeps your code simple, secure, and easy to debug, even if it's web-only. I'd argue that anything else is just due to lack of experience. A service layer also makes the work on a project more parallelizable in terms of number of developers that can work together on it, each focusing on their part of the puzzle, without breaking each other's code all the time.
  - tensor 12y ago
    But then your service layer has potential SQLi issues. Moving the problem doesn't make it go away. Many of the clojure SQL libraries solve this by using prepared statements by default. This is not a hard problem.
    - mantrax3 12y ago
      If it's "not a hard problem" - and I agree it isn't, and it's solved by Clojure's SQL libraries, why should the web framework deal with it in any way? And moving the problem actually helps, when the original place was the wrong place to solve the problem. Security is one problem when you write queries all over the place. The other two problems are data integrity, and maintenance. In a service layer you have exactly three concerns: 1) Validate abstract input (and permissions of the caller). 2) Perform the transaction. 3) Return abstract output (and/or errors). No routers, no controllers, no views, no templates, no CSRF, no XSS, no HTML escaping, no GET, no POST, no nothing. Just input, transaction, output. Pure data. Pure business logic. And suddenly things that seemed hard to get right, or things you had to repeat all over the place in your code, get done simply, and just once. And all your web code calls the service layer. All your iOS and Android app code - also calls the same service layer. And they're both secure because you need to get the service secure just once - then all interfaces (web, mobile, desktop, API) use the same service. And when you don't isolate the service, you'll be running SQL all over the place, and use every framework's souped up solutions to avoid SQLi. Which one do you feel is better?
      - lukeschlather 12y ago
        I've seen SQLi blindly passed from frontend code to a backend service API and then executed. The indirection did help mask the issue so there was no suggestion the attack succeeded or way that it could actually be exploited, but it's perfectly possible to what you describe without actually solving the sanitization problem. SOA is great for scalability, but not really that much of a boon for security (especially since you now have a problem of authentication between your frontend service and your backend service which is often ignored since it's behind the firewall and nobody is going to be snooping.) (Other than the NSA, GHCQ, and China.)

collyw 12y ago

It shouldn't be but that's not always possible.

mantrax3 12y ago
It is always possible. Name one case where it isn't, and I'll tell you how it's possible :) Web frameworks should handle input (routing, request fields, url query) and output (templates). That's it.
- collyw 12y ago
  OK, Django ORM, conditional aggregates - these were not possible last time I checked. You can do it at the application level, but say you want to keep the performance up, you need to drop into SQL.

joevandyk 12y ago

Virtually all web frameworks encourage SQL. So it is a problem. Making a private api to access the database can add a lot of needless complexity.

mantrax3 12y ago
That private API is called a service layer, and without it, your code devolves into copy/paste spaghetti. We live in an age when having a complementary iOS/Android app for your site is not the exception anymore. Without a service layer you'll have coupled your services with your web pages. Connecting your server with your apps will be quite painful. You don't want that. Done right, your service layers keeps your code simple, secure, and easy to debug, even if it's web-only. I'd argue that anything else is just due to lack of experience. A service layer also makes the work on a project more parallelizable in terms of number of developers that can work together on it, each focusing on their part of the puzzle, without breaking each other's code all the time.
- tensor 12y ago
  But then your service layer has potential SQLi issues. Moving the problem doesn't make it go away. Many of the clojure SQL libraries solve this by using prepared statements by default. This is not a hard problem.
  - mantrax3 12y ago
    If it's "not a hard problem" - and I agree it isn't, and it's solved by Clojure's SQL libraries, why should the web framework deal with it in any way? And moving the problem actually helps, when the original place was the wrong place to solve the problem. Security is one problem when you write queries all over the place. The other two problems are data integrity, and maintenance. In a service layer you have exactly three concerns: 1) Validate abstract input (and permissions of the caller). 2) Perform the transaction. 3) Return abstract output (and/or errors). No routers, no controllers, no views, no templates, no CSRF, no XSS, no HTML escaping, no GET, no POST, no nothing. Just input, transaction, output. Pure data. Pure business logic. And suddenly things that seemed hard to get right, or things you had to repeat all over the place in your code, get done simply, and just once. And all your web code calls the service layer. All your iOS and Android app code - also calls the same service layer. And they're both secure because you need to get the service secure just once - then all interfaces (web, mobile, desktop, API) use the same service. And when you don't isolate the service, you'll be running SQL all over the place, and use every framework's souped up solutions to avoid SQLi. Which one do you feel is better?
    - lukeschlather 12y ago
      I've seen SQLi blindly passed from frontend code to a backend service API and then executed. The indirection did help mask the issue so there was no suggestion the attack succeeded or way that it could actually be exploited, but it's perfectly possible to what you describe without actually solving the sanitization problem. SOA is great for scalability, but not really that much of a boon for security (especially since you now have a problem of authentication between your frontend service and your backend service which is often ignored since it's behind the firewall and nobody is going to be snooping.) (Other than the NSA, GHCQ, and China.)