I. Web Sins Overview A. New part of course ------------------------------------------ SECURE CODING Second part of the course - secure web implementation - secure coding - secure crypto coding - secure networking ------------------------------------------ II. SQL injection A. overview ------------------------------------------ WHAT IS A SQL INJECTION ATTACK? 1. Database App 2. Attacker 3. App uses In Java: public static boolean doQuery(String id) { /* ... */ ResultSet rs = st.executeQuery( " SELECT ccnum FROM cust " + " WHERE id = " + id); /* ... */ } ------------------------------------------ Why is this code a problem? ------------------------------------------ SERIOUSNESS OF SQL INJECTION ATTACKS #1 flaw on the OWASP top 10 list (2013). - easy to exploit - severe impact Can put "all data in a database at risk." Can lead to legal liability: - Calif.'s online privacy protection act - Germany's Fed. Data Protection Act - Sarbanes-Oxley act (in US) must protect data used to derive company financial statements - PCI data security standard (DSS) - HIPPA ------------------------------------------ B. generalization ------------------------------------------ DOES IT ONLY APPLY TO SQL? ------------------------------------------ ------------------------------------------ A CAREFUL PERSPECTIVE Limit user input to the smallest Validate user input by Form a more complex query by ------------------------------------------ 1. tainting ------------------------------------------ TAINTING A static analysis that tracks values derived from String i; i = input(); String j = i; runit(j); void runit(String id) { String k = myQuery + id; st.executeQuery(k); } ------------------------------------------ is k tainted? ------------------------------------------ TAINTING & CONSERVATISM String i; i = input(); String j; if (cond()) { j = i; } else { j = "27"; runit(j); runit("32"); void runit(String id) { String k = myQuery + id; st.executeQuery(k); } ------------------------------------------ Is the executeQuery call sinful? ------------------------------------------ GENERALIZTION Should only compute with data that User inputs don't! Tainted data = ------------------------------------------ C. Prevention ------------------------------------------ PREVENTION OVERVIEW Tools: - CAT.NET for MS .NET work, an add-on to Visual Studio - Perl taint checking (perl -T) Best: Code reviews focusing on SQL injection Poor: Look for specific attacks in input ------------------------------------------ Why is looking for specific attacks poor? What happens if you remove "delete" from "deldeleteete"? 1. steps ------------------------------------------ PREVENTION STEPS Never trust Do NOT form queries using Use prepared/parameterized SQL statements In Java: public static boolean doQuery(String arg) { Pattern p = Pattern.compile("^\\d{1,8}$"); if (!p.matcher(arg).find()) { return false; } /* ... */ PreparedStatement st = con.prepareStatement( "exec pubs..sp_GetCreditCard ?"); st.setString(1, arg); ------------------------------------------ What does it mean to validate a string? What security service does trusting user input violate? What does that pattern in the Java code mean? 2. other defenses ------------------------------------------ DEFENSE IN DEPTH Encrypt data that is: sensitive, PII, or confidential Access control: - deny access - only allow access - use least privilege Do not embed Do not store ------------------------------------------ III. Web server related attacks (XSS, XSRF, and Response Splitting) A. example 1. type 1 attacks (non-persistent) ------------------------------------------ CROSS-SITE SCRIPTING (XSS), TYPE 1 Idea: 1. Design URL containing 2. Get user to click on that URL 3. Web server puts the script on web page that is 4. The browser In JSP: <%= request.getParameter("Name") %> In Ruby on Rails: <%= comment.body %> ------------------------------------------ How do you get step 2 to work? Why doesn't the attacker run the script themselves? What role does the web server play in this? What security service does this violate? B. severity ------------------------------------------ SEVERITY OF XSS Very common Easy to find using a browser ------------------------------------------ C. other types of xss attacks 1. type 2, persistent xss attacks ------------------------------------------ STORED XSS ATTACKS (TYPE 2) Like type 1, but the malicious query is 1. Send input containing 2. Get user to browse that web site 3. Web server puts the script on web page that is 4. The browser runs the malicious script ------------------------------------------ What kinds of web sites store user input and show it to others? Is there social engineering necessary to make this work? 2. response splitting ------------------------------------------ RESPONSE SPLITTING Puts malicous script in In Ruby on Rails: redirect_to(url) ------------------------------------------ What's the problem with the rails code? 3. cross-site request forgery (XSRF) ------------------------------------------ CROSS-SITE REQUEST FORGERY (XSRF) Occurs when website designed to use query strings in URLs to e.g., in email app: http://ex.com/request.php?create-new http://ex.com/request.php?read-NNN http://ex.com/request.php?delete-NNN ------------------------------------------ Why is that design a problem? D. prevention 1. xss prevention ------------------------------------------ DETECTION (FOR XSS) Code review: look for reading from a request object and Testing: set all inputs to a known IBM Security AppScan CAT.NET ------------------------------------------ ------------------------------------------ PREVENTION (FOR XSS) Don't trust Validate inputs Encode output (HTML encoding or URL encoding) Take CRLF out of input that goes into headers Set a default character set: ------------------------------------------ How could you validate inputs? Why does HTML or URL encoding help? Why use a default character set? 2. for xsrf ------------------------------------------ PREVENTION (FOR XSRF) 1. Use a secret value to authenticate the client to the server, and don't 2. Give the session a timeout 3. Use POST (instead of GET) ------------------------------------------ What good does the timeout do? Why use POST instead of GET? IV. web client related vulnerabilities A. gadgets and widgets ------------------------------------------ GADGETS AND WIDGETS affect gadgets and widgets What is a gadget or widget? Examples: ------------------------------------------ What are some examples of gadgets or widgets you have seen? What technology is used to program gadgets and widgets? B. attack description ------------------------------------------ TYPE 0 XSS ATTACK 1. gadget or widget takes input from 2. gadget or widget renders Example (JavaScript): if (XMLHttpRequest) { xhr = new XMLHttpRequest(); } else { xhr = new ActiveObject("MSXML2.XMLHTTP.3.0"); } xhr.open("GET", url, true); if (xhr.responseXML) { xmlDoc = xhr.responseXML; results.innerHTML = xmlDoc...; } ------------------------------------------ ------------------------------------------ BUGGY RSS FEED HEADLINES GADGET g_viewElements.FeedItems[i].innerHtml = feedItemName; ------------------------------------------ What could happen if feedItemName is tainted? C. prevention ------------------------------------------ PREVENTION Don't trust Don't use innerHTML, instead use Don't use insertAdjacentHTML, instead use Consider using ------------------------------------------ V. Magic URLs, Predictable Cookies, Hidden Form Fields A. overview/description 1. magic URLs ------------------------------------------ MAGIC URLs def: a *magic URL* is one that example: ex.com?id=TXkkZWNyZStwQSQkdzByRA== ------------------------------------------ What's going on in that URL? 2. predictable cookies ------------------------------------------ PREDICTABLE COOKIES Using a value that is not E.g., incrementing the value after authentication ------------------------------------------ 3. hidden form fields ------------------------------------------ HIDDEN FORM FIELDS Putting important data in a "hidden" form field Can clients see it? Can clients change it? ------------------------------------------ 4. Summary ------------------------------------------ WHAT'S THE COMMON PROBLEM? Pattern: 1. sensitive information taken from a cookie, HTTP header, form, or URL 2. Data is used in security decisions 3. Data is sent over an insecure channel How would an attacker exploit this? 1. Gather information from web pages using 2. Create altered versions of that info 3. Send that back to the server ------------------------------------------ What other attacks could happen? ------------------------------------------ PREVENTION Use code review Look for requests (Java: getRequest() and request.GetParameter()) Hidden form fields type="hidden" Testing tools: TamperIE firefox Web Developer fiddler2 ------------------------------------------