SEC835

1. SEC835 OWASP Top Ten Project

2. Top Ten Web App Vulnerabilities • OWASP top ten web application vulnerabilities – 2007 report • Vulnerabilities • A1 - Cross Site Scripting (XSS) • A2 - Injection Flaws • A3 - Malicious File Execution • A4 - Insecure Direct Object Reference • A5 - Cross Site Request Forgery (CSRF) • A6 - Information Leakage and Improper Error Handling • A7 - Broken Authentication and Session Management • A8 - Insecure Cryptographic Storage • A9 - Insecure Communications • A10 - Failure to Restrict URL Access

3. Top Ten Web App Vulnerabilities • OWASP top ten web application vulnerabilities – 2010 report • Vulnerabilities • A1 - Injection Flaws • A2 - Cross Site Scripting (XSS) • A3 – Broken Authentication and Session Management • A4 - Insecure Direct Object Reference • A5 - Cross Site Request Forgery (CSRF) • A6 – Security misconfiguration • A7 - Insecure Cryptographic Storage • A8 - Failure to Restrict URL Access • A9 – Insufficient transport layer protection • A10 – Unvalidated redirect and forwards

4. Cross-Site Scripting and Injection Flows • See Week 10 materials

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

6. IDOR Protection • Avoid exposing direct object references to users by using either of • an index, • indirect reference map, • or other indirect method that is easy to validate. • If a direct object reference must be used, ensure that the user is authorized before using it. • Validate any private object references extensively with a white list approach

7. Cross-Site Request Forgery • CSRF forces a victim browser to send a request to a vulnerable application, after a user is logged-on. A user can be tricked by an image link for example. • A vulnerable application (or html page) starts acting on behalf of a user, using the opened session. It can perform actions designed by the attacker, e.g. transfer money from the victim account • Affected page performs the action that appears to come from a legitimate user • The malicious code often resides on other site, not on the victim site, that’s why named as cross-site

8. Cross-Site Request Forgery • XSS exploits the trust a user has for a particular site, when CSRF exploits the trust a site has for a particular user • CSRF occurs when the application rely solely on automatically submitted credentials such as session cookies, basic authentication credentials, source IP addresses, SSL certificates, or Windows domain credentials.

9. CSRF Protection • A user must be re-authenticated by generating and then requiring some type of authorization token that is not automatically submitted by the browser. • Insert custom random tokens into every form and URL that will not be automatically submitted by the browser • For sensitive data or value transactions, re-authenticate or use transaction signing • Do not use GET requests (URLs) for sensitive data or to perform value transactions. Use only POST methods when processing sensitive data from the user • POST alone is not sufficient. It must be combined with random tokens and re-authentication • Limit the lifetime of authentication cookies • Ensure that there are no XSS vulnerabilities in your application. XSS vulnerabilities are not required for CSRF success but may aggravate the CSRF result

10. Security misconfiguration Security holes that occur due to wrong, weak, or contradicted configuration parameters Mostly relate to network and servers configuration

11. Security misconfiguration protection Standard hardening procedures must apply to all infrastructure sw/hw Updates and patching Application code version control

12. Insecure cryptographic store • The most common problems are: • Not encrypting sensitive data • Using home grown algorithms • Insecure use of strong algorithms • Continued use of proven weak algorithms (MD5, SHA-1, RC3, RC4, etc…) • Hard coding keys, and storing keys in unprotected stores

13. Strong crypto mechanism • Do not create cryptographic algorithms. Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. • Do not use weak algorithms, such as MD5 / SHA1. Favor safer alternatives, such as SHA-256 or better. • Generate keys offline and store private keys with extreme care. Never transmit private keys over insecure channels • Ensure that infrastructure credentials such as database credentials or MQ queue access details are properly secured (via tight file system permissions and controls), or securely encrypted and not easily decrypted by local or remote users • Ensure that encrypted data stored on disk is not easy to decrypt. For example, database encryption is worthless if the database connection pool provides unencrypted access.

14. Strong crypto mechanism (cont) • Data in rest must be encrypted with the highest possible granularity, relevant to the data’s sensitivity classification. • Field encryption will be implemented for highly sensitive data. • Data files, folders, or whole-disk encryption can be used to protect data as a batch function. However, if the data contains sensitive items, then field encryption must be implemented prior to using bulk encryption • Encryption keys must be protected at the same level or higher as the data.

15. Strong crypto mechanism (cont) • All keying materials must be destroyed immediately after use. • Encryption keys must not be hardcoded • Encryption keys must not be stored in audit logs. • An encryption key can be used for one purpose only. • Memory protection • Allocate two different buffers used for: • Plaintext data • Encrypted data • Erase data traces from the buffers immediately after use.

16. Failure to restrict URL access • Access to web pages thru “hidden" or "special" URLs, rendered only to administrators or privileged users in the presentation layer, but accessible to all users if they know it exists • Access to “hidden” files, such as static xml files without authorization • Code that enforces an access control policy but is out of date or insufficient • Code that evaluates privileges on the client but not on the server

17. URL access protection • Role-based access control to the application functions • Always ensure that administrative and high privilege actions are protected • Locate application libraries outside of the web root • Block access to all file types that your application should never serve

18. Insufficient transport layer protection • Failure to encrypt network traffic for all authenticated connections • Common flaws: • Only login activity is protected with SSL • Backend communication is not protected

19. Insufficient transport layer protection • Communication to end user always occurs over SSL • All sensitive actions are protected, not only login • Backend communication is protected with TLS

20. Unvalidated redirects and forwards Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

21. Unvalidated redirects and forwards - protection Avoid using redirects and forwards If used, don’t involve user parameters in calculating the destination. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.

22. For 2007 items See below

23. Malicious File Execution • Occurs when a developer accepts file names or files from a user without validation • Typical examples include: .NET assemblies which allow URL file name arguments, or code which accepts the user’s choice of filename to include local files. • A common vulnerable construct: • include $_REQUEST['filename’];

24. Malicious File Execution (cont) • Other methods of attacks: • Hostile data being uploaded to session files, log data, and via image uploads (typical of forum software) • XML documents submitted by an attacker may have a hostile DTD that forces the XML parser to load a remote DTD, and parse and process the results

25. Protection • This vulnerability is difficult to determine • Automatic testing is not capable to validate the use of parameters • Security remedy must start from the architecture and design • Ensure that the application will not use user-supplied input in any filename for any server-based resource (such as images, XML and XSL transform documents, or script inclusions), and will have firewall rules in place preventing new outbound connections to the Internet or internally back to any other server.

26. Protection (cont.) • Recommendations • Use indirect object reference map • Strong user data input validation (white list strategy) • Check any user supplied filenames or files • In Java, consider implementing a chroot jail or other sandbox mechanisms in order to isolate applications • In J2EE, ensure that security manager is enabled and permissions are controlled

27. Information leakage See week 9 materials

28. Lab task • Read OWASP Top Ten Project Articles • Work on your spreadsheet • Crypto: cells E3, A19 • IDOR: cells D3, A26 • XSRF: cells F3, A21, A23 • URL access: cells C3, A5 • Transport Layer: cells G3, A24 • Redirects and forwards: cells H3, A25

29. Useful links https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet