The Essence of Command Injection Attacks in Web Applications

1. The Essence of Command Injection Attacks in Web Applications Zhendong Su and Gary Wassermann Present by Alon Kremer April 2011

2. Outline Command injection attacks in web application Formal definition of web application Formal Definition of command injection attack An algorithm to prevent those attacks

3. Attacking the Web Application • Web application: • takes input strings from the user and interprets it. • Interacts with back-end database. • Retrieve data and dynamically generates new content. • Presents the output to the user. • The threat – Command Injection Attack: • Unexpected input may cause problems.

4. Database query Web page Web Application Architecture Application generates query based on user input User input Result Application Database Web browser

5. SQLCIAs - Example String query = “SELECT cardnum FROM accounts WHERE username = ‘” + strUName + “’ AND cardtype = ” + strCType + “;”; Expected input: SELECT cardnum FROM accounts WHERE username = ‘John’ AND cardtype = 2; Result: Returns John’s saved credit card number.

6. SQLCIAs - Example String query = “SELECT cardnum FROM accounts WHERE username = ‘” + strUName + “’ AND cardtype = ” + strCType + “;”; Malicious input: SELECT cardnum FROM accounts WHERE username = ‘John’ AND cardtype = 2 OR 1 = 1; ( ) ( ) Result: Returns all saved credit card numbers.

7. Web Application – Formally • A function from n-tuples of input strings to queries strings. • It doesn’t check changes in the query structure or gives information about the source of the strings. “SELECT cardnum FROM ccards WHERE name = ‘John’ AND cardtype = 2” h “John”, “2” i

8. Quick Overview • Many web applications are vulnerable and lots of private records can be exposed in 1 attack. • Ways to regulate user inputs • Filter out “bad” strings. (‘O’brian’ ?) • Escape quotes. ( 2 OR 1=1 ?) • Limiting input’s length. • Regular expression, etc. • The cause of problems is that the input changes the syntactic structure of whole query.

9. SQLCIAs – Informally

10. SQLCIAs – Informally • SQLCIA – modifies syntactic structure of a query. • Our goal is to track user inputs with metadata: m and n so the input is syntactically confined in the augmented query. • Modify SQL grammar to include metadata: nonterm::=msymboln • Attempt to parse augmented query • Fails ) block; Succeeds ) allow.

11. Valid Syntactic Forms • Given G = {V, , S, P}, choose policy of input we want to allow U µ V [  • VSF idea is that the parse tree has a node in U which has an input substring as descendants. b_term::=b_termANDcond cond::=val comp val val::=num | id comp::= < | > | = … 3 < x U = { cond } 2 OR 1 = 1

12. SQLCIAs – Formally Query qis a SQLCIA if • q has a parse tree Tq . • For some filter f and some input i: • f(i) is a substring in q and is not a VSF in Tq .

13. Augmented Query • Our goal is to track and identify the user input inside the query (in the parse tree). • By augmenting the input to mikn we can determine which substrings of the constructed query come from the input. • A query qa is an augmented query if it was generated from augmented input. qa =W(mi1n,…,minn)

14. Augmented Grammar • Given: G = {V, , S, P}and Uµ[V • An augmented query qa is in L(Ga) iff • qis in L(G), and • for each substring S that separates a pair of matching m,n, if the meta-characters are removed then S is VSF. • Ga= {V[ {ua | u2U},[ {m,n}, S, Pa} ua : fresh non-terminal Pa = {v!rhsa | v!rhs2P} [ {ua!u | u2U} [ {ua!mun | u2U}

15. Augmented Grammar • {v!rhsa | v!rhs2P} construct production rules that all “Right Hand Side” occurrencesof u2Uare replaced with ua • Example: U = { b, D } S::=bCD C::=c D::=d | dd S::=baCDa ba::=mbn | b C::=c Da::=mDn | D D ::=d | dd P = Pa =

16. Theorem For all i1,…,in, W(mi1n,…,minn) = qa2L(Ga) iff W(i1,…,in) = q2L(G) and q is not an SQLCIA.

17. Implementation • Meta Characters- two random four letters strings, except dictionary words. Total of • Most user inputs are dictionary words, passwords with numbers or other then 4 letters, so the probability for using the meta-characters is • The policy U is defined in terms of which non terminals in SQL grammar are permitted to be at the root of VSF.

18. bool bool … bool::=terma terma::=term |mtermn term::=faca faca::=fac |mfacn … Online terma terma m n term term m n faca faca Database Web Browser Application fac fac m n m n Implementation G Offline G’ SQL grammar augment Augmented SQL grammar Parser Generator SQLCheck U Policy • use randomly generated strings SQLCheck returns q if qa2L(Ga)

19. Test Subjects • Two languages (PHP & JSP): • Most techniques require a language-specificfront-end; ours does not

20. Evaluation RTT over internet: ~80-100ms

21. Conclusions • Formal definition of SQLCIAs and an algorithm to prevent them by syntactically constrain substrings from user input. • SqlCheck intercepts all queries and check their syntactic form. • Suitable for different languages and web interfaces.

22. Future Work • Experiment with more real-world online web applications and more sophisticated testing techniques. (input place holder). • Apply to XSS, Xpath injection, etc.

23. A few thoughts about the article • The formal definition of the web application and the SQLCIA referred to the most common and basic properties. • The algorithm was simple and elegant.This solution suits for all web apps even in different programming languages. • Easy to control the input policy. • The evaluation was not tested versus attackers attempting to defeat this particular mechanism.