for detecting SQLi attacks from user input • Released at BlackHat USA 2012 • Tokenizes user input as if it were SQL • Then matches token-stream against known SQL attacks • Currently in IronBee and ModSecurity WAFs
there was no standardized, measurable open source solution for detecting SQLi. • The ones that existed were mostly collections of regular expressions, without unit tests or other QA. • How do you know how well it works? Or if it works at all?
• Version 3.9.1 • 20 number of tokens — and could use more! • 8000+ SQLi fingerprints • 30+ rules for folding together tokens • 400+ unit tests • 85,000+ SQLi samples
was done by using SQLi attack scanners. • Unfortunately, I learned they are not equivalent to skilled attackers. At all. • SQL is a lot larger, and more diverse than I expected. • Many many bypasses found initially. • Big thanks to @rsalgado and @modsecurity team and many others
server is not involved (100% client-side problem). • Javascript unlike SQL is highly dynamic and error tolerant. • Detecting javascript ‘fragments’ without context is near impossible to do accurately and with precision.
sure…if you are expecting full HTML inputs • Most inputs are not HTML, which means you’ll be rejecting a lot of inputs. • <nickg@client9.com> would be rejected since it’s not a whitelisted tag. • Fairly large, language-specific libraries • Not a practical solution
IE only has a few versions • The tokenizer didn't change that much • Well-known exceptions to the rule • HTML5 was designed to mostly match existing behavior anyways
security problem which is an open question into another known, solved problem. • ‘Detecting XSS’ -> how do you QA? How do you know if you are correct? • ‘Detecting XSS’ -> Tokenizing HTML5. Completely testable in a positive case. Now the detecting XSS part is much much smaller.
• Handling broken, nested tags: hard • Defining exact order of operations with script tags: hard • Defining what tags actually do: hard and evolving • Rendering: hard. • HTML5 Tokenization: easy and well-defined.
its based on tokenization so there is additional context. • ‘onerror’ as-is, is NOT an injection • ‘onerror’ with an value, is (requires ‘=‘ afterwards, an non- empty value). • Should have better false positives and false negatives • How else are you going to do it? • Likely to need refinement
— so it’s likely to have some spectacular failures (bypasses) • False Positive QA not completed. • Currently does not handle some IE injections • Does not have a test-bed for experimenting (maybe later this week). • More QA, code-coverage needed • No bindings for scripting languages (soon).
SoCal. See you next year! —nickg If you have any questions on libinjection, please see https://libinjection.client9.com/ or email me at nickg@client9.com
Nick Galbreath
ngalbreath
reverentgeek
rmw
skipperchong
carmenhchung
keathley
productmarketing
clairelew
thoeni
jcasabona
