Attacks Against Websites 3 The OWASP Top 10 Tom Chothia Computer Security, Lecture 14
OWASP top 10. The Open Web Application Security Project Open public effort to improve web security: Many useful documents. Open public meetings & events. There 10 top lists the current biggest web threats.
But First: Apple s TLS Bug 1. C S : N C 2. S C : N S, Cert S 3. C S : E S (K_seed), {Hash1} K CS 4. S C : {Hash2} K CS Hash 1 = #(N C,N S, E S (K_seed)) Hash 2 = #(N C,N S, E S (K_seed), {Hash1} K CS ) K CS is a session key based on N C, N S & K_seed,
TLS vs TLS-DHE 1. C S : N C 2. S C : N S, Cert S 3. C S : E S (K_seed), {#(All previous messages)} K CS 4. S C : {#(All previous messages)} K CS 1. C S : N C 2. S C : N S, g x, Cert S, SignS(#(N C,N S,g x )) 3. C S : g y, {#(All previous messages)} K CS 4. S C : {#(All previous messages)} K CS K CS is a session key based on N C, N S & g xy,
Apple s TLS-DHE 1. C S : N C 2. S C : N S, g x, Cert S, True 3. C S : g y, {#(All previous messages)} K CS 4. S C : {#(All previous messages)} K CS K CS is a session key based on N C, N S & g xy,
Simple MITM attack: 1. C S : N C 2. S E(C) : N S, g x, Cert S, Sign S (#(N C,N S,g x )) 2. E(S) C : N S, g z, Cert S, Sign S (#(N C,N S,g x )) 3. C E(S) : g y, {#(messages)} K CS1 4. E(S) C : {#(messages)} K CS1 3. E(C) S : g w, {#(messages)} K CS2 4. S E(C) : {#(messages)} K CS2 K CS1 is a session key based on N C, N S & g zy, K CS2 is a session key based on N C, N S & g xw,
Major issues ios fixed days before Mac OS! Why didn t tests pick this up? Compiler should warned of unreachable code. Bad programming style: no brackets, goto: http://xkcd.com/292/
OWASP top 10. The Open Web Application Security Project Open public effort to improve web security: Many useful documents. Open public meetings & events. There 10 top lists the current biggest web threats.
A1: Injection Server side command injection, e.g., SQL injection. Not just SQL injection, any command language can be injected. E.g. PHP, shell commands, XML processing commands,
A2: Broken Auth. Many web developers implement their own log in systems. Often broken, e.g. No session time outs. Passwords not hashed E.g. password shame list.
A3: XXS Cross Side Scripting attacks, as discussed. A1 injection is command injection on the server side. This is JavaScript injection on the client side.
A4: Insecure Direct Object Reference Problem: the server trusts the client to request only the resources it should. E.g. http://site.com/view?user=alice! which we could replace with:! http://site.com/view?user=bob! Also common with cookie values.!
Path Transversal The user can type anything they want into the URL bar, or even form the request by hand. http://nameofhost/../../../etc/shadow If the webserver is running with root permission this will give me the password file.
Path Transversal: Fix Use access control settings to stop Path Transversal. Best practice, make a specific user account for the webserver. Only give that account access to public files.
A5: Security Misconfiguration Make sure your security settings don t give an attacker an advantage, e.g. Error Messages: should not be made public. Directory Listings: It should not be possible to see the files in a directory. Admin panels should not be publically accessible.
A6: Sensitive Data Exposure All sensitive data should be protected at all times. Is SSL used everywhere? Credit card numbers not encrypted: CC no. should be encrypted in database. PHP page should decrypt these, if needed. This means that the hacker needs to attack the page and the database.
A7: Missing Function Level Access Control Query strings are used to tell dynamic webpages what to do http://mywebshop.com/index.php? account=tpc&action=add http://mywebshop.com/index.php? account=tpc&action=show What if the attacker tries: http://mywebshop.com/index.php? account=admin&action=delete
URL hacking The user can type anything they want into the URL bar, or even form the request by hand. http://nameofhost/filepath Attacker can try to guess filenames, Guessable directory names will be found.
Fix No security through obscurity Never rely on just the URL request for authentication. E.g. Use cookies to control access.
A8: CSRF Cross-Site Request Forgery (CSRF) As discussed earlier. Defend against by using unique token in the hidden field of important forms.
A9: Using Components with Known Vulnerabilities If a new security patch comes out has it been applied? A patch might require you to bring down the site and so lose money. Or it might even break your website. Is it worth applying the patch?
A10: Invalidated Redirects and Forwards If attackers can forward a user to another page then they can use it for: Phishing (e.g. a fake log in page) Ad Fraud. Launch exploits on browser. Not a major threat (IMHO).
Conclusion To secure a website you need to know how it works: How clients request resources. How clients are authenticated. How HTTP and webservers work. Errors are often down to bad app logic Always sanitize everything.