Web Security Fundamentals

Common Attacks
Best Practices
Architecture
SQL Injection
HTML Injection

Same Origin Policy
XSS
XSRF
Sessions Hijacking

Password security
Salting/Hashes/Crypto
SSL

Transcript

1. WEB SECURITY FUNDAMENTALS Kevin Campbell @kevcampb Jimmy Wong @wong_jim Hong Kong Python User Group 16th Feb 2013
2. Today’s focus • The changing state of web application development • Code injection and sanitising inputs • Cross site scripting, request forgery • Sessions, cookies • Passwords • Hashes, MAC, crypto • Network security
3. Why is Security Important Banking Site: • All your customer's funds could be transferred to Dr. Evil Shopping Site: • You could lose customer credit card info Webmail Service Site: • Lose emails with login information to above sites Cat Picture Sharing Site: • Lose email addresses and passwords for webmail services
4. Common Threats • Worms and automated attacks ◦ Very common for publically released software packages ◦ Keep up to date with latest security fixes • Targeted hacking ◦ Dedicated hackers are very difficult to defend against • Malware on end users machines ◦ The simplest way to compromise user accounts • Internal threats ◦ For corporate environments, the most common risk • Information leakage ◦ Permissions model allows access to data which shouldn’t be ◦ With more data sharing, an increasingly complex problem
5. Common Threat Categories • Defacement • Infiltration • Denial of Service (DOS) • Data theft and loss • Phishing • Pharming (AKA DNS spoofing, DNA Cache Poisoning) • DNS hijacking
6. Security Best Practices • Principle of Least Privilege • Defence in Depth ◦ Condom over onion ◦ Prevent, Detect, Contain, Recover • Harden the Weakest Link • Simplicity ◦ Simple systems are far easier to audit and harden
7. Architectural Overview
8. Where we are today • Security is getting harder • Handling more user data than before • More results faster, being agile • Devops, Web Services, Cloud Computing • Much more likely to see XSS, than buffer overflows now • Huge range of platforms (mobile devices, browsers, apis)
9. Early Web Application
10. Early web applications • Relatively simple app, only some write opera • Data sent by HTTP POST from html forms • Backend maybe in CGI, mostly static content • Buffer overflows a significant attack vector • Cared about your apache version, kernel and firewall • Either using system package management or building from source
11. Web application frameworks
12. Web application frameworks • Now running a more complex web framework • Additional software packages for webapp • AJAX used for dynamic page content • SQL Injection attacks and XSS a concern • Still care about the underlying system
13. Complex web apps
14. Complex web apps • Running on cloud services • Lots of attack surface area • Increasing complexity of Javascript code • Difficult to apply test driven development • Your code is visible to the public
15. Complex web apps Javascript code is getting more and more complex Vulnerabilities can exist anywhere for code injection
16. Complex web apps • Increased number of data sources • Not always in full control of those data sources • Harder to test, need to develop stubs and mock objects
17. Packages and config management • Lots of 3rd party code in use in your system • Incredible number of dependencies • Less clear gap between systems and development • Fast release cycles, continuous deployment • Hard to keep track of revisions • Could easily be including malicious code
18. Dealing with complexity • Package management systems can help • Deb / RPM , PIP / Virtualenv, Javascript assets • Only use trusted sources • Don't include packages you don't need • Track revisions to have an audit trail (pip freeze) • Keep up to date with security releases
19. Code Execution Security Flaws
20. SQL Injection • Non sanitized inputs passed to SQL query string def displayUserInfo(request, email_input): db.execute(“““ SELECT name, age FROM person WHERE email = ‘%(email)s’ ””” % {‘email’: email_input}) • If database allows ; to be entered then attacker will be able to enter additional queries • Should always use placeholders where possible
21. SQL Injection
22. SQL Placeholders • Placeholders will safely escape any input passed def displayUserInfo(request, email_input): db.execute(“““ SELECT name, age FROM person WHERE email = %s ”””, (email_input,)) • Defined in PEP 248 but some variation on syntax • If not possible to apply placeholder, database layer will provide an appropriate escape(…) method for you
23. ORM and Query Builders These will handle escaping for you, making life easier Django ORM from django.db import models class Person(models.Model): first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=30) search_results = Person.objects.filter(first_name='John') SQLAlchemy users = Table('users', metadata, Column('user_id', Integer, primary_key=True), Column('name', String(40)), Column('age', Integer), Column('password', String), ) users.select(and_(users.c.age < 40, users.c.name != 'Mary'))
24. HTML Injection Similar to SQL injection, unescaped input can lead to including arbitrary HTML code var image = { width: "240", height: "230", title: "User image", img: "user1039.png" }; var image_tag = '<img title="' + image.title + '" width="' + image.width + '" height="' + image.height + '" src="' + image. img + '" />'; jQuery(image_tag).appendTo('#some-selector');
25. HTML Injection Similar to SQL injection, unescaped input can lead to including arbitrary HTML code var image = { width: "240", height: "230", title: "User image", img: "user1039.png" }; image.img = 'user1039.png" /><img src="dummy'; var image_tag = '<img title="' + image.title + '" width="' + image.width + '" height="' + image.height + '" src="' + image. img + '" />'; jQuery(image_tag).appendTo('#some-selector');
26. HTML Injection - Why it's bad • We can now run arbitrary javascript code image.img = 'user1039.png" /><img src="doesntexist.png" onerror="alert(\'owned\');"/>; • Use of <img onerror=... is to avoid conflict. You cannot nest <script> inside a <script> block. • If "user1039.png" was built using "user" + username + ".png", a user could set their username to attack the site. • If the broken code was on a forum, anyone viewing that user's posts would get their account compromised • Problem is made worse when combining in XSS
27. Preventing HTML injection Validate and HTML escape user input like before & &amp; < &lt; > &gt; " &quot; ' &#39; HTML HTML Character Entities
28. jQuery safety Some jquery methods are unsafe, particularly .append() and the jquery selector $('') which can also create nodes $('<img>') will generate a img node Only a few jquery methods should be passed unescaped input Safe methods .text() .attr() .prop() .val() Unsafe methods .html() $() .append*() .wrap*() .prepend*() .before() .after() .insert*()
29. HTML templates Using a templating language for generating HTML will greatly reduce mistakes - if used correctly! Underscore.js Safe: <%- var %> Unescaped: <%= var %> Handlebars / Mustache Safe: {{ var }} Unescaped: {{{ var }}}
30. Cross-Domain Security
31. Same Origin Policy Same Origin • http://www.example.com/a • http://www.example.com/b • http://www.example.com/a/c?d=e Different Origin • https://www.example.com • http://example.com • http://www.example.com:8080/ • http://www.iamevil.com Scripts can only access methods and attributes of objects from the same origin. (Same scheme, domain, port)
32. Cross-Site Request Forgery Same Origin Policy only constraints resources running inside the browser. Anyone can still make HTTP requests to your server.
33. Cross-Site Request Forgery http://evilhacker.org <form action="http://example.com/userprofile" method="POST"> <input type="hidden" name="user@email.com"> <input type="hidden" name="password" value=" letmein"> .... </form> <img src="icon.png" onclick="form.submit()" /> http://example.com • /userprofile accepts POST requests to modify emails and passwords
34. Cross-Site Request Forgery Email and passwords changed for every user in your database. EvilHacker says: All your accounts are belong to us.
35. Preventing XSRF • Solution 1 ◦ Require users to enter their credentials before allowing them to access their personal info page ◦ Advantage: ▪ Easy to understand and implement ◦ Disadvantage: ▪ Extremely annoying for many use cases • Solution 2 ◦ Use a XSRF (CSRF) action token
36. Preventing XSRF with a token <form action="/userprofile" method="POST"> <input type="hidden" name="token" value="thetoken" /> ... </form> def handleFormInput(request): if not check_token(request.POST.get('token',None)): raise SecurityError("CSRF Check Failed")
37. Preventing XSRF with a token T = MAC(K MAC ,C + d + L) K MAC = Application-specific key C = Cookie data unique to every browser session d = A string delimiter L = The path of your site to grant access to MAC = A message authentication code algorithm e.g. HMAC T = Token
38. Preventing XSRF with a token • Don't invent your MAC implementation • If your frameworks gives you functions to generate and extract CSRF tokens, use it. ◦ Django ▪ https://docs.djangoproject.com/en/dev/ref/contrib/csrf/ ◦ Flask ▪ http://pythonhosted.org/Flask-WTF/ ◦ Blueberrypy ▪ https://github. com/wyuenho/blueberrypy/blob/master/src/blueberrypy/util. py#L362
39. Cross-Site Scripting (XSS) Example: http://www.example.com/blogs?keyword=apple+%3Cscript% 3Esomeeviljs%3C/script%3E Result: <ul> <li> <a href="/blogs/apple-pie">Apple Pie<a/> <script> // some evil script that steals your login cookie </script> </li> </ul>
40. Preventing XSS Escape URLs before inserting them into href and src attributes • Javascript ◦ $().attr() for inserting into DOM attributes • Python ◦ import urllib (Percent encoding) ▪ urllib.quote ▪ urllib.quote_plus ▪ urllib.urlencode ▪ urllib.pathname2url ◦ import htmlentitydefs (Ampersand encoding)
41. Preventing XSS Python data[0]['var'] = '"}]); $. POST("somewhereevil", ...);'; Jinja2 JS Template Backbone.Model({% str(data) %}); Result Backbone.Model([{"var": ""}]); $.POST ("somewhereevil", ... Beware of poorly structured code that renders JS/CSS templates from the server side
42. Preventing XSS • Solution 1 ◦ Don't allow anything with weird symbols from user input • Solution 2 ◦ import re; re.escape() # doesn't speak Unicode in 2.x • Solution 3 ◦ Use a code path that invokes a proper JSON serializer • Solution 4 ◦ Don't write these ugly code in the first place
43. Session Hijacking
44. What is a Session? • HTTP is a stateless protocol ◦ Does not prescribe a way to store state on the client side • Websites need to customize for individual users ◦ Bring your session ID with you for every request ◦ Session Cookie ▪ Session ID, with expiry date
45. Session Hijacking by ID Fixation Scenario 1 1. Evil Hacker goes to http://www.example.com? sessionid=12345 2. Evil Hacker sends Tom Cruise an email with the URL 3. Tom Cruise signs up to the Church of FSM with that session 4. Evil Hacker visits URL and change Tom Cruise's password
46. Session Hijacking by ID Fixation Scenario 2 Same as scenario 1, substitute session cookie with query string. Scenario 3 There's a browser vulnerability, Evil Hacker can set a session ID to any arbitrary domain - unlikely, but possible given browsers are now getting more and more like OS.
47. Preventing Session Hijacking • Use a different session ID for every request ◦ AKA invalidate the last session ID on the server and set a new session ID in the response for every request ◦ CherryPy / blueberrypy does this by default ◦ Django? Flask? • Use "secure" cookie attribute ◦ Only gets sent over HTTPS • Use "HttpOnly" cookie attribute ◦ Accessible only from HTTP/S, no Javascript access
48. Password
49. Hashes, Passwords • Never store user passwords in plaintext • A one way hash stores a password in a way you can check it but not get the original data MD5("The quick brown fox jumps over the lazy dog") = 9e107d9d372bb6826bd81d3542a419d6 • SHA256, PBKDF2 or bcrypt now recommended over SHA1 or MD5 • Salting is essential to avoid rainbow table attacks • Don't roll your own, use your language or framework • Don't use easily guessable passwords, especially 'joe accounts'
50. Random Numbers • Session ID generation needs to be secure • Pseudo-random number generators are often predictable • Secure random numbers are either generated using environmental noise, or a hardware generator • For python, do not use the random.random, instead use random.SystemRandom or ssl.RAND_bytes • Using too much secure random data can deplete the entropy pool
51. Random Numbers
52. Cryptography
53. Asymmetric Cryptography • System has two keys, one public, one private. • Can be used to both encrypt and sign data • The public key is safe to give out. It can be used to encrypt data that only you can read, or check a signature that you have applied to a document. • Only the private key can decrypt data or sign documents
54. Asymmetric Cryptography Source: http://www.data-processing.hk/glossaries/public-key-encryption/
55. Asymmetric Cryptography -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is my file. I have many such files. But this is the file I'm working with now. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (MingW32) iQIVAwUBPOCy1mM8BmRItYg4AQKWrA//fR5LKFyt+78CMtfpzkHgCVFyEe2ImsBy FJ2HvzRIP4Bvor1iEOZ9A0fux8gBNXrvEtaDXSiGyXH+Ru4F3g1+K119fgBPRBgo oOTbSLZSlRYWp8mRALsiWXKEHWgpy4zIHVTY6tPJdxFBZYJXnQj/4S6MRP+eJdam rU8ufExxaqQPw+KCNEVCSk1yHZ886k6MTSa1oDqUOLiM1cBDCtD8Jv+BE0gLHPb9 1h7lEka8QGNe+P7iiUzvsuD7HCL6dGb6T70/KBBHIP6lDwOgUX3eTd8e+I3jczs9 RyEmd6G4swM3IzCD1km+SN5/k5QsMjd6Lw5fB95Mroi47QNpya8ifYbMgCg0+BVm c7QOwr79+9cJiKhEICbMf5pKQWzP/AznaYlM0IOGGCvxa5loLl7BbtvktVMocitF zWM9SB0kmSu3OlMxjXYcBsyHCHN4dTpCD9d1jfbgth9YV06sWpONLohdaWx+n9kO CxsSDGI+aW8sGKHWonw0Uy4UAvUzY3tiZTzTF+FzoJzhy13KK1j4Y0MMx1jZ68f9 R9wSKVdiyXwuMXkWWK0uxSZuBz4mTofZ7YmFm7UdxOH4bMnO+rWNCSPR7md+X0j1 nQSwtxEnIu7Tucb/ZG3t9kR+KTByPTu7tHINr4HFd8m2Cu7Wi10TP/EBtXbtYA/1 SBaUXcbgCD8= =Hn6O -----END PGP SIGNATURE----- A signed document using GnuPG
56. Asymmetric Cryptography • Primarily based around the RSA algorithm, which involves finding factors of large prime numbers • Private key allows you to easily compute results that would be near impossible without knowing the content of that key • Foundation of most internet security (SSL, SSH, GPG, HTTPS, Signed applications) • We aren't going to try and explain RSA today!
57. Asymmetric Cryptography Generating SSL keys Kevins-MacBook-Pro:~ kev$ openssl genrsa -aes128 -out my.key 2048 Generating RSA private key, 512 bit long modulus .....++++++++++++ ........++++++++++++ e is 65537 (0x10001) Enter pass phrase for my.key: Verifying - Enter pass phrase for my.key: Resulting key file -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,84408B2B3E1D8C91A1EAFC1996665B6F z5USZhPA7ipo1qByz0djXeFrXBdFaZHp0dnn2JFUXn+QJzplOiR49Bo9oPbFsZA/ bQmpleo4awHrTkVSg/LABXnfI3bRwzYg0nWLk9po1Z1128IEynuWK53n//uWrzsJ ShQ2KaG/NPrPZmk0egq84TbjHKr9SWBV6QvhfyrzjH7uKkeTbVeRF1+tzBOyWL6i sjTo099XTwRiT2wHfKJ4hspyiBgye+IbayxqQzTjZPssa+WaXL/zMrHAVry8AxCA 22XaOzCUhYLO+x/nFE2v43WT7VlVB0tKARZT5AOQFnsvUWOLev3/iAGWs2CcAi6e 0VJ18pVNexIjLz87JcdhKLN1vHCp9696cYpb62rlLPZctPJHMfpa1BzxtZVcAZjT kddoN5LPjoAFOxalhk2HJAQez/Ode3Iafwgh0dnLn6TH6gM8NwJiRN3JP7vka17V
58. Asymmetric Cryptography Exporting the public key Kevins-MacBook-Pro:~ kev$ openssl rsa -in my.key -pubout Enter pass phrase for my.key: writing RSA key -----BEGIN PUBLIC KEY----- MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANoUz++JFdygugdxgLpnRdrEczq0HCHw dFr1IIKSwN+loxBDrx0F0CLkPCtlxtvJ09r8QgEb5dVsDMw2kdnRUksCAwEAAQ== -----END PUBLIC KEY-----
59. Symmetric Cryptography • In symmetric cryptography, both systems have a copy of the same shared key that they use to communicate • Simplest version is the one time pad • Real symmetric algorithms have complex systems of modifications and rotations. • Much faster than asymmetric cryptography • Often combined with asymmetric (public key) cryptography. This used to share an initial symmetric key. • Most commonly used is AES encryption which is used in SSL
60. Certificate and SSL/TLS • SSL certificates make use of asymmetric cryptography. • Obtained from a certificate authority who uses their private key to sign your certificate. • You have your own private key to that certificate which you can then use to sign data and prove your identity. • Data is encrypted between the webserver and the browser • Your private key must be kept secure and needs to be stored on the webserver.
61. Certificate and SSL/TLS • Browsers have a list of trusted authorities that they recognise. This list is continually updated. • Different levels of SSL certificate have different background checks to prove who you are. • System only as good as the weakest link in the chain • Some recent high profile attacks have happened due to authorities being compromised.
62. Resources • CVE (Common Vulnerabilities and Exposures) ◦ Issue security alerts for common software products • Web Application Hackers Handbook • Foundations of Security: What Every Programmer Needs to Know • Same Origin Policy (Google Browsersec) • Applied Cryptography
63. Question / Discussion Over to you
64. Thank You How to find us: • Facebook ◦ https://www.facebook.com/groups/hkpug/ • Google+ ◦ https://plus.google. com/communities/101733318682537087614 • (Google for Hong Kong Python User Group) • Kevin Campbell @kevcampb • Jimmy Wong @wong_jim