4 ms·

The most severe vulnerability submitted and the highest awarded was a SQL Injection. Can someone explain why this is still in existence? With the plethora of w

by smaili 10y ago

The most severe vulnerability submitted and the highest awarded was a SQL Injection. Can someone explain why this is still in existence? With the plethora of web frameworks and built in parameterization and ORM abstraction, I don't understand how this can still be exploited. Especially when we're talking about the Pentagon of all places.

ourmandave 10y ago
These are the guys that still use floppy disks to run the nuclear program. http://www.cnn.com/2016/05/26/us/pentagon-floppy-disks-nuclear/ http://www.cnn.com/2016/05/26/us/pentagon-floppy-disks-nucle... So probably on a legacy system before SQL injection was a thing.
tetrep 10y ago
Legacy code? It can't be very surprising that entities, especially the government, aren't quick to refactor old, "just works" code.
- malux85 10y ago
  This is exactly it. From what I have found, these places either have 1) No programming resource internally. 2) Some programming resource internally, but they're so swamped with other, poorly managed timeframes and projects, there's no extra resources. So Light to Medium sized projects get outsourced - but if the delivered product "works" (at least visually) then who is going to QA the code? In fact, go one step back -- who is even going to think that the code needs to be checked? The management who chose the vendor? Hell no, that would look bad for them. The programmers who are swamped on other projects? Hell no, they're so busy they dont even want to talk to you. So management takes one glance at it, see's that it works, and it gets thrown into production. The first time it's security is tested, is when the international hackers come knocking... I'm not defending these actions in any way - I think it's a goddamn joke - but this is the reality
onion2k 10y ago
Practically every framework gives a developer the capability to run raw SQL queries on a database. The latest version of the popular PHP framework Laravel still has DB::raw. Express in NodeJS uses the NPM MySQL client that offers connection.query for raw SQL. Python's Flask framework uses SQLAlchemy and gives a developer db.engine.execute access. And so on for every language people make database driven websites in. Using a framework well stops SQL injection attacks dead in their tracks. Using one badly though, and they're still just as dangerous.
- jrcii 10y ago
  Although we can agree we should be sanitizing inputs, I haven't seen a consensus on the use of ORM as a best practice and wouldn't say its employment is inherent in using a framework well. There's nothing wrong with writing SQL queries if everything leading up to that point is handled correctly.
  - jerf 10y ago
    The pattern I've seen on a recurring basis is: 1. You need a query that can't be handled by your ORM, since in general ORMs can't expose all functions of a database. (This condition is also met if you have no ORM.) 2. You need a query that is going to have a varying number of parameters, so you need to manually assemble the query. When that happens, there's a temptation in almost all systems to try to write the moral equivalent of: sql_query = "WHERE condition = '" + param1 + "' if something: sql_query += " AND other_thing = '" + param2 + "' " and so on and so on. This is where I see most of the SQL injection, even in language communities that have otherwise thoroughly internalized the need for query parameters (for example, perhaps surprisingly, the Perl community for a very long time). Programmers who are not really fluent yet and are still having to think about every line either don't think about, or are trying to avoid the complexity of, sql_query = "WHERE condition = ?" params.append(param1) if something: sql_query += " AND other_thing = ? " params.append(param2) are the source. This pattern is, broadly speaking, safe. But it has just that extra bit of the sort of complexity that a lot of programmers shy away from. (As opposed to the sorts that programmers almost seem to chase, like "adding 15 boolean parameters to a function over the course of a year".) There's also usually a library in the target language that is a pretty good reflection of SQL that avoids this problem (such as SQLAlchemy in Python), but I think that most people consider this "too complicated".

by smaili 10y ago

ourmandave 10y ago

These are the guys that still use floppy disks to run the nuclear program. http://www.cnn.com/2016/05/26/us/pentagon-floppy-disks-nuclear/ http://www.cnn.com/2016/05/26/us/pentagon-floppy-disks-nucle... So probably on a legacy system before SQL injection was a thing.

tetrep 10y ago

Legacy code? It can't be very surprising that entities, especially the government, aren't quick to refactor old, "just works" code.

malux85 10y ago
This is exactly it. From what I have found, these places either have 1) No programming resource internally. 2) Some programming resource internally, but they're so swamped with other, poorly managed timeframes and projects, there's no extra resources. So Light to Medium sized projects get outsourced - but if the delivered product "works" (at least visually) then who is going to QA the code? In fact, go one step back -- who is even going to think that the code needs to be checked? The management who chose the vendor? Hell no, that would look bad for them. The programmers who are swamped on other projects? Hell no, they're so busy they dont even want to talk to you. So management takes one glance at it, see's that it works, and it gets thrown into production. The first time it's security is tested, is when the international hackers come knocking... I'm not defending these actions in any way - I think it's a goddamn joke - but this is the reality

onion2k 10y ago

Practically every framework gives a developer the capability to run raw SQL queries on a database. The latest version of the popular PHP framework Laravel still has DB::raw. Express in NodeJS uses the NPM MySQL client that offers connection.query for raw SQL. Python's Flask framework uses SQLAlchemy and gives a developer db.engine.execute access. And so on for every language people make database driven websites in. Using a framework well stops SQL injection attacks dead in their tracks. Using one badly though, and they're still just as dangerous.

jrcii 10y ago
Although we can agree we should be sanitizing inputs, I haven't seen a consensus on the use of ORM as a best practice and wouldn't say its employment is inherent in using a framework well. There's nothing wrong with writing SQL queries if everything leading up to that point is handled correctly.
- jerf 10y ago
  The pattern I've seen on a recurring basis is: 1. You need a query that can't be handled by your ORM, since in general ORMs can't expose all functions of a database. (This condition is also met if you have no ORM.) 2. You need a query that is going to have a varying number of parameters, so you need to manually assemble the query. When that happens, there's a temptation in almost all systems to try to write the moral equivalent of: sql_query = "WHERE condition = '" + param1 + "' if something: sql_query += " AND other_thing = '" + param2 + "' " and so on and so on. This is where I see most of the SQL injection, even in language communities that have otherwise thoroughly internalized the need for query parameters (for example, perhaps surprisingly, the Perl community for a very long time). Programmers who are not really fluent yet and are still having to think about every line either don't think about, or are trying to avoid the complexity of, sql_query = "WHERE condition = ?" params.append(param1) if something: sql_query += " AND other_thing = ? " params.append(param2) are the source. This pattern is, broadly speaking, safe. But it has just that extra bit of the sort of complexity that a lot of programmers shy away from. (As opposed to the sorts that programmers almost seem to chase, like "adding 15 boolean parameters to a function over the course of a year".) There's also usually a library in the target language that is a pretty good reflection of SQL that avoids this problem (such as SQLAlchemy in Python), but I think that most people consider this "too complicated".