No More Injection
Really! It’s time to move on to other topics. So today I want to close out on our discussion of application injection with some final reader’s comments. Next time we will be moving on to another topic of interest.
One thing I would encourage you to look into if you haven’t heard the term before is Blind Injection. This is a method where an attacker finds things out about your system, primarily a database engine, by the behavior of the application.
Simply because an attacker may append additional SQL statements to a data entry field, it doesn’t necessarily tell them anything. However, if an attacker enters an SQL Statement, the statement fails, and that failure causes the application to behave differently than if it succeeds, the attacker can now determine things about your database engine by the app working or failing.
Using this behavior, an attacker simply asserts things about your storage, and your application provides them with a true or false response. For example they could assert that the login to the data store is “HACKER”. Your application would have a failed behavior telling them that the login is not in fact “HACKER”. Using this knowledge they are not getting the actual value, but they are able to determine that a fact about your system.
Blind injection is not quick, similar to using a dictionary search to figure out a password. However, using it in conjunction with other injection techniques, it can allow you to circumvent other barriers. Take a look; it is an interesting topic.
Readers Comments
David:
This tip, "Restrict the number of characters allowed in your controls to the maximum allowed in your persistence. Web controls with no text limits provide a rich environment for injection attempts.", Needs to be qualified with the statement that these restrictions need to be enforced on the server side. Any 12 year old with Firefox & Firebug can eliminate a client-side character restriction on a form with just a few clicks (right-click the form element, click inspect, then click on the maxlength property and hit the delete key).
Just think of it this way: anything you send down as HTML, CSS, or JS is just a recommendation to the user on how to access your server, and if you don’t know who’s actually accessing your server, you can’t trust them, and your code shouldn’t trust them.
Personally, I’d push this to every interface layer, turning the web app into a “loose federation” of related entities that collaborate most of the time, but never trust each other (for reasons such as the two-level injection I mentioned in an e-mail I sent a few days ago).
(On another note, this level of compartmentalization can have the added benefit of making new additions to the “federation” easier. If the layers are always watching out for bad behavior, you can add new functionality, such as a phone app in parallel to your server-side/client-side code, or a REST API not intertwined with your MVC framework, without needing to re-architect the communication layers.)
Steve:
Something to note about the stored procedure below. Since most injections are going to be updates (the encoded injections that I’ve analyzed have all been updates since it is the path of least resistance) and are appended to the existing code, the stored procedure below would in most cases do little or nothing to alleviate an issue. It also does not take into account characters that are cast or converted from non-decimal and non-alpha related injections such as have been circulating after the UN debacle.
Better to catch key words such as cast, convert and exec and ensure they only have limited options. As you stated if you primarily ensure the data types are managed then 90% of the problem has been resolved and you only need to monitor for a limited set of reserved words such as those above.
I still get attempts coming in with the encoded injections daily and haven’t had any issues when using these techniques in combination with some up front security measures.
Thanks for all the great feedback. Your suggestions and experiences are always appreciated. Feel free to write in with things relevant to you at btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Three Ways To Be Productive Using SharePoint and SQL Server (Part 1)
In the first part of my three-part series on increasing productivity when using SharePoint and SQL Server, we will focus on searching product data from the Adventure Works database, including the use of meta-data and managed properties.
Featured White Paper(s)
Web Content Management
Written by AvePoint
The power of the World Wide Web has dramatically change… (read more)