Wednesday 31 July 2013

Another example why SATS technology needs custom rules (re: Detecting SQL Injection on .NET Entity framework)

In Darren's great SQL Injection with Entity Framework 5 and Static Code Analysis post, he mentions how all SAST tools he used failed to find this security vulnerability:


The reason is simple: None of the tools he used had the Database.SqlQuery Method marked as a Sink (and btw last time I checked FxCop is not a SAST tool)

One of the things I wanted to do this week was to add a rules manager/editor to CAT.net (see my current research on this SAST tool from Microsoft here), and this could a good example (i.e. show how to write a custom CAT.Net rule to detect this security issue).

On the topic of documentation, it would be nice if the MSDN documentation pages on these methods mentioned the SQL Injection dangers:

Actually looking at the Database class, there are a couple other dangerous methods (assuming the attacker can control the string value):
Question: Is there a list of all Linq and Entity framework methods that need to be marked out as Sinks? (for a SAST engine)