code by the sea: web application security

46

Upload: boy-baukema

Post on 15-Apr-2017

45 views

Category:

Software


2 download

TRANSCRIPT

Boy BaukemaSecurity Specialist @

Ibuildings.nl

Security what?• Senior Engineer

+ interest in WebAppSec

+ 4 hours a week R&D

+ internal training & consultancy

+ internal & external auditing

– Ibuildings CTO

“Make security something I can sell, give managers a knob to turn.”

Application Security Verification Standard

Level 1 Level 2 Level 3

1.1 X X X

1.2 X X

2.1 X X X

2.2 X

• Finance and Insurance

• Manufacturing, professional, transportation, technology, utilities, infrastructure, and defense

• Healthcare

• Retail, food, hospitality

V2.16 Verify that credentials are transported using a suitable encrypted link and that all pages/functions that require a user to enter credentials are done so using an

encrypted link.

Level 1

2.26 Verify re-authentication, step up or adaptive authentication, two factor

authentication, or transaction signing is required before any application-specific sensitive operations are permitted as

per the risk profile of the application.

Level 2

8.12 Verify that the logs are stored on

a different partition than the application is running with proper

log rotation.

Level 3

IANAL

http://www.nu.nl/internet/4322459/bijna-helft-van-nederlandse-gemeenten-meldde-jaar-datalek.html

Data leak notification requirement

• A vulnerability !== a leak

• Leaks must be reported within 72 hours

• Failure to report may result in fine up to EUR 820.000 (UPDATE: €20.000.000 or 4% of worldwide revenues)

Which data?• Personal data:

• Credentials

• Financial

• Identifying (identity theft risk)

• Stigmatizing or sensitive (religion, sexual preference, etc.)

Examples data leak• Logs

• Stolen laptop / USB stick

• rm -rvf / (without backup)

• Malware infection

• Printing users[0] on frontpage

Examples data leak

• Shoulder surfing in train while in customer backend

• Third party developer accessed customer data

• Data centre fire

• Mailing with CC instead of BCC

A1 - Injection• Content

• SQL / DQL

• XML (XXE)

• URL

• Command / Shell

• LDAP

• Memcached

• Solr

• AngularJS

• Redis

Content / URL

• http://www.rtlnieuws.nl/node/1842021/nos-is-beter

• http://vulnerablesite/suggestions.php?stockid=123&stockrecommendation=We+Really+Recommend+You+Sell+This+Stock+Now

XXE

<?xml version="1.0"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

Memcached

Memcached

Solr

http://host:port/solr/core/update?stream.body=<delete><query>*:*</query></

delete>&commit=true

{! rows=5000000}

AngularJS

• {{constructor.constructor('alert(1)')()}}

Redis

The Redis protocol has no concept of string escaping, so injection is impossible under normal circumstances using a normal client library. The

protocol uses prefixed-length strings and is completely binary safe.

A2 - Broken Auth & Sess

• Credentials over HTTP

• Brute forceable credentials

• Session fixation

• Infinite Session length

A3 - XSS

• How do you encode plain text from JavaScript?

• Why do we even care about this with browser XSS detection?

• How does Content-Security-Policy help?

A4 - Direct Object Refs

Session Fixation

• ?PHPSESSID=abc123

JSON Web Token

A5 - Security Misconfig• Is any of your software out of date? This includes the OS, Web/App

Server, DBMS, applications, and all code libraries (see new A9).

• Are any unnecessary features enabled or installed (e.g., ports, services, pages, accounts, privileges)?

• Are default accounts and their passwords still enabled and unchanged?

• Does your error handling reveal stack traces or other overly informative error messages to users?

• Are the security settings in your development frameworks (e.g., PHP.ini, Drupal, Symfony, etc) and libraries not set to secure values?

A6 - Sensitive Data Exposure

• Is any of this data stored in clear text long term, including backups of this data?

• Is any of this data transmitted in clear text, internally or externally? Internet traffic is especially dangerous.

• Are any old / weak cryptographic algorithms used?

• Are weak crypto keys generated, or is proper key management or rotation missing?

• Are any browser security directives or headers missing when sensitive data is provided by / sent to the browser?

A8 - Cross Site Request Forgery

https://security.linkedin.com/blog-archive#11232015

Clickjacking LinkedIn

A9 - Using Known Vulnerable Components

A10 - Unvalidated Redirects & Forwards

• https://slack.com/checkcookie ?redir=http://www.likelo.com

• https://www.wepay.com/v2/oauth2/authorize ?client_id=112736 &redirect_uri=http://www.maliciousurl.com &scope=send_money

• window.opener