I was given a list of SQL keywords. The idea was that a hacker trying to break the database via a UI or Fiddler/server would be defeated because that (black)list would contain every SQLServer keyword short of ‘select’ (that’s another story). So it would be something like (‘drop’,’delete’,’truncate’) etc. And of course the example assumes that there is no stored procedure with parameters, or ORM, or whilelisting to protect the database. Just effectively plain old unfiltered SQL hitting the database and being allowed to execute dynamic sql, with no parameter binding. So I was being asked to validate the list as being comprehensive.
Well, no blacklist in the world is going to be comprehensive enough, I think. That is because you can obfuscate your intention by passing a hex string as a parameter to e.g.
or somesuch. (I guess you could blacklist [convert] etc.)
Anyway, pressing on with my (flawed 🙂 ) evil call…
Suppose you could pass this in your textbox or Fiddler call…
Well, you clearly couldn’t say it was harmless… as you just don’t know. In fact this is the result when executed against SQLServer 2014:
This is how I built the hex string:
, and this is the full picture:
Use fiddler, the WCF binary plugin for Fiddler and SQL profiler. Challenges I’m seeing in attempting to reproduce an attack: Because the ui login times out, the auth cookie is no longer valid, and you have to rerun the ui login. Solution (ignoring security)… Extend the ui timeout. That’s SessionTimeout . &pos; as a single quote worked yesterday, but today it appears that does not work… But single quote does work. Clearly my environment has changed. I am quite sure I have not taken a new build. And I know that it should be ‘ but it did work, I have the screen shots, your Honour. Https: for ease of use , the demo will not include this. In Fiddler, if I enter bad syntax, when that request gets sent, the query goes through but the additional syntax is not there. Much later, it turned out that you don’t need any escaping for this particular query. The use of a semi colon is immediately identified as the delimiter of two statements, and SQL profiler shows that quite nicely OneNote is a good place to record all your attempts… Before the event, because after, you will not remember what you did. So you will probably need to throw away 90% of your work and prep, because it did not yield what you wanted Once you become familiar with the pattern of how code is written, you could imagine that you could automate it to look for those patterns. And attempt to inject malicious SQL at various points which might follow other patterns you have seen.