Addressing Injection Attacks in Languages and Libraries

A short talk about approaches to preventing injection attacks (SQL, XSS, etc.) in applications at the library and programming language level.

Presented at the Ruxmon Perth security meetup in August, 2012.

Transcript

1. Addressing Injection Attacks in Languages and Libraries
2. Injections Attacks • When data are treated improperly – usually at system boundaries – and are executed as code.
3. General Form input <- $WORLD[‘unsafe’] command <- “please do $input” execute($command)
4. Targets • Generated HTML output • SQL & LDAP queries • System commands • Method names, etc.
5. How can programming languages and libraries help?
6. Usability • Effectiveness - the goals of use of the overall system are achieved. • Efficiency - the resources that have to be expended. • Satisfaction - users find the overall system acceptable.
7. Usability • Either most software doesn’t have a requirement: “must be secure” • Or: most software tools have poor usability in this respect.
8. Usability • Safety and correctness should not be “nice to have”. • We should not have to remember to do things properly. • If a tool doesn’t help to achieve our goals, it’s a bad tool.
9. Improvements • Default to safe handling methods. • Enforce safe handling methods. • Restrict APIs and build trusted kernels.
10. Safe by default • Handle data safely by default. • Example: template language in Django framework. • Variables interpolated into output are escaped by default. • Requires no special effort to be safe.
13. Safe by default • When all escaping happens automatically in the libs “escaping” a value is idempotent: just set (or clear) the flag. • Neither “&” nor “&amp;amp;” will be a problem again!
14. Enforce safety • Tools used in contexts where security is important should enforce safety: potentially unsafe actions should not occur. • Perl’s tainting mechanism is a good example.
15. Tainting • Tainting is usually a tool which marks certain data as being “tainted” or dirty in certain circumstances: • Data from untrusted sources in perl. • Linux kernel running closed source modules. • Dynamic, run-time property.
16. Perl’s taint mode • [A]utomatically enables a set of special security checks, called taint mode, when it detects its program running with differing real and effective user or group IDs. • Also enabled explicitly by using the -T command line flag.
17. Perl’s taint mode • “You may not use data derived from outside your program to affect something else outside your program--at least, not by accident.” • “Laundering data using regular expression is the only mechanism for untainting dirty data”
18. Perl’s taint mode • Encompasses many data which can affect dynamic properties of software: • command line arguments • environment variables • locale information • system calls • file input
19. Restricted APIs • If users abuse functionality to do silly things, then take remove the functionality.
20. Restricted APIs • Design library APIs to suit the task at hand. Client code shouldn’t build strings of SQL, LDAP, HTML, etc. code unless it’s the best option! • It’s hard to write an injection vulnerability without interpolation and/or concatenation!
21. Restricted APIs • Instead use techniques like: • Newtype wrappers (FP) • Smart constructors (FP) • Private inner classes (OOP)
22. Restricted APIs • The mysql-simple and postgresql-simple Haskell libraries exemplify this approach. • Instead of taking a query as a String (or ByteString, or Text, etc.) they expect a Query value. • A string literal can be a Query in the same way 1 can be an Int, a Double, etc.
25. Restricted APIs • Under the covers this Query is just a ByteString (an array of bytes, just like C strings). • From the client programmers perspective, it’s almost entirely opaque. This interface is safe. • (Until we notice fromString, at least.)
26. Conclusion • Many of the problems which plague the software industry are problems of user interface design. • Techniques and patterns have been known for decades can reduce or remove entire classes of errors. • But we don’t use them.