![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Break Dejector!
Dejector, the anti-SQL-injection-attack tool which I developed based on the ideas outlined in this paper, now has a live proof-of-concept up and running. Try and break it! Tell your friends, get them to try and break it too! Pimp it on IRC, submit it to Slashdot, I don't care. This thing needs stress-testing.
As the page explains, it's using a weird dialect of SQL, but that's not intended to be security through obscurity; I learned bison for this project, so I relied on the SQL89 grammar in the O'Reilly Lex and Yacc book. Consider this a .0001a release; the real one will be a C++ library built on the flex/bison (or, in MySQL's case, handrolled-lexer/bison) definitions from a variety of open-source SQL dialects, with wrappers for Python, PHP and whatever other languages SWIG supports and people care about.
As the page explains, it's using a weird dialect of SQL, but that's not intended to be security through obscurity; I learned bison for this project, so I relied on the SQL89 grammar in the O'Reilly Lex and Yacc book. Consider this a .0001a release; the real one will be a C++ library built on the flex/bison (or, in MySQL's case, handrolled-lexer/bison) definitions from a variety of open-source SQL dialects, with wrappers for Python, PHP and whatever other languages SWIG supports and people care about.
no subject
no subject
~j
no subject
no subject
As far as packaging it up for the future... something Java compatible will be useful to more of the developers "who need it" than any other language IMHO.
no subject
I know there are Java-based parser generators, but having already ported one lexer/parser to another language, I really don't fancy doing it again. Still, you're absolutely right -- something that will play nicely with JDBC will be crucial.
no subject
*points out a typo in the paper* Page 4, in the footnote.
I also dislike your example in the SQL section, since by allowing the "'" character in the password the "malicious" input becomes a "valid" password, and this should be recognised by the developer who should escape the input before using it in the query. Although I assume that you've had that comment more than once! In the real world - validate inputs AND use prophylactic code.
One other thing that I noticed was that you stated regexp as insufficient for validation, but in cases where the language of the context you are validating is simple enough regexp would be sufficient - they just are not sufficient for the general case.
I'm firmly of the opinion that all computer software designs should have a big sign on the cover saying "pragmatism required". ;)
no subject
Yup, we have. The counterpoint is that there are occasions where escaping input ends up mangling your data, thus creating an error from the other direction. Strangely, I think something like that ended up in the talk outline but somehow not in the paper.
in cases where the language of the context you are validating is simple enough regexp would be sufficient
Certainly. OTOH, I can't think of any programming languages which have a syntax that can be described by a regular expression ...
Where's the typo, btw? Is it supposed to be "implementers"?
no subject
It would be easier to write if I could remember how to do superscript in html...
The a^m b^n I presume ought to be a^m b^m, since it's trivial to regexp the first, and the second requires self-reference.
no subject