Save 37% off PRO during our Black Friday Sale! »

Web Security Fundamentals

Web Security Fundamentals

Common Attacks
Best Practices
SQL Injection
HTML Injection

Same Origin Policy
Sessions Hijacking

Password security


Jimmy Yuen Ho Wong

February 16, 2013


  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), ) < 40, != '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 • • • Different Origin • • • • 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 <form action="" method="POST"> <input type="hidden" name="">

    <input type="hidden" name="password" value=" letmein"> .... </form> <img src="icon.png" onclick="form.submit()" /> • /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 ▪ ◦ Flask ▪ ◦ Blueberrypy ▪ https://github. com/wyuenho/blueberrypy/blob/master/src/blueberrypy/util. py#L362
  39. Cross-Site Scripting (XSS) Example: 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 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:

  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 ◦

    • Google+ ◦ com/communities/101733318682537087614 • (Google for Hong Kong Python User Group) • Kevin Campbell @kevcampb • Jimmy Wong @wong_jim