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
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
in Depth ◦ Condom over onion ◦ Prevent, Detect, Contain, Recover • Harden the Weakest Link • Simplicity ◦ Simple systems are far easier to audit and harden
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)
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
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
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
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
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
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
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
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*()
greatly reduce mistakes - if used correctly! Underscore.js Safe: <%- var %> Unescaped: <%= var %> Handlebars / Mustache Safe: {{ var }} Unescaped: {{{ var }}}
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)
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
+ 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
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
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
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
◦ 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
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
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.
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
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'
• 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
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
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
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!
-in my.key -pubout Enter pass phrase for my.key: writing RSA key -----BEGIN PUBLIC KEY----- MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANoUz++JFdygugdxgLpnRdrEczq0HCHw dFr1IIKSwN+loxBDrx0F0CLkPCtlxtvJ09r8QgEb5dVsDMw2kdnRUksCAwEAAQ== -----END PUBLIC KEY-----
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
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.
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.
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
• Google+ ◦ https://plus.google. com/communities/101733318682537087614 • (Google for Hong Kong Python User Group) • Kevin Campbell @kevcampb • Jimmy Wong @wong_jim