Web Application Security - Amazon S3 · •Security engineer during the day • Design review •...

transcript

Web Application Security

• Security engineer during the day

• Design review

• Code review

• Pentest

• Developer/DevOps at night

• Docker/Nginx/Apache

• Rails/Go/Python/PHP

About me

Agenda

• Random thoughts and advice around web application security

• Case study on my personal website

• Future of web application security

What makes a web application secure?

Security needs to be easy and opt-out• Pick a framework with mature libraries for:

• Database management:

• Developers should rarely write SQL

• User management

• Developers shouldn’t need to write user management

• This is actually really hard to get right

• Output escaping in views:

• Not escaping data should be a conscious decision, not the default

Security needs to be easy and opt-out• Examples:

• Ruby-on-Rails, Spring, .Net framework with MVC, Angular

• Counter-examples:

• raw-PHP, raw-???

• The latest cool stuff on HN

Secure development• Really hard problem to solve

• Off-The-Shelf products are often limited:

• not based on your context

• not based on developers’ skill-set

• What is worse than a dev that you train on secure development and leave your organisation…

Don’t use blacklist

Using a blacklist is gambling on whether or not your security knowledge is and will stay stronger than your

strongest opponent's…

Example of how hard it is to create a white-list: https://fin1te.net/articles/safecurl-ssrf-protection-and-a-capture-the-bitcoins/

The Bug Factor• Way to measure security of a system (based on https://

en.wikipedia.org/wiki/Bus_factor)

• How many bugs away are you from

• a full compromise (shell)?

• your database on pastebin?

• …???

The Bug Factor

• Increasing your bug factor:

• Network segregation

• Principle of least privilege

• Defence in depth

Alerting

• Every time something triggers an error in your application, you should be notified (email, Slack, IRC)…

• This is not even a security problem… this happens to also solve a security problem

Transport Layer Security• Should be mandatory

• Very easy/cheap/minimal performance impact:

• AWS certificate manager

• Let’s encrypt

• HTTP vs self-signed certificate?

HTTP Security headers

• You can greatly improve the security of your web application by justing adding some HTTP headers:

• limit the impact of an XSS

• prevent being iframed.

• …

HTTP Security headers: HSTS• HTTP Strict Transport Security

• Ensure people always visit your site over TLS

• Strict-Transport-Security: max-age=31536000

• Supported by most browsers

• Effort to deploy/maintain: small

HTTP Security headers: CSP• Content-Security Policy

• Allow a developer to white-list content for CSS, JavaScript and Images

• 2 modes: report and block

• CSP 1 supported by most browsers, CSP 2 almost only supported by Chrome

• Effort to deploy/maintain: CSP 1 (high), CSP 2 (medium)

HTTP Security headers: HPKP

• HTTP Public Key Pinning

• Prevent rogue/compromised CA to intercept users’ communication

• Supported by Chrome and Firefox

• Effort to deploy/maintain: medium

Secrets and source code

• Keeping your keys and credentials outside of the source code is a difficult problem:

• Credentials can be packaged with the source code at build time

• Credentials can be on the system (file or environment variables)

What keeps an application secure over time?

A. Input filtering

B. Output escaping

C. A Web Application Firewall with a learning engine

D. Automated testing and automation

E. Chuck Norris

What keeps an application secure over time?

A. Input filtering

B. Output escaping

C. A Web Application Firewall with a learning engine

D. Automated testing and automation

E. Chuck Norris

Why?Security is constantly evolving, what will make your application secure is your ability to secure it now, but also to keep it secure over time.

To keep an application, it needs to be constantly patched (new attacks vector, new vulnerabilities in a dependency, …)

It’s not “Do you patch”, it’s “When do you patch”

Your application has security issues or potential security improvements, being able to easily test and deploy fixes or improvements will allow you to keep it secure

Spend your money on patching automation, not vulnerability management

Computing is cheap, people having meetings on risk assessment ain’t

Patching, patching, patching

http://martinfowler.com/bliki/FrequencyReducesDifficulty.html

If something is hard, do it often!

Case study: pentesterlab.com

• Pretty simple web application

• Manages users (registration, authentication, password reset, …)

• Allow to download public and private content

• Online exercises

• Ruby-on-Rails

• HTML escaping by default

• No need to write any SQL query

• I’m already subscribed to the security mailing-list

• Very smart people reviewed the codebase

• Very talented people are using it

• Alerting:

• Exception notification library:

https://github.com/smartinez87/exception_notification

• User management:

• devise library (https://github.com/plataformatec/devise)

• Registration, Confirmation, Password Hashing, Lock-out…

• Sharing public content (ISO file):

• Early version hosted on the same server

• Version 2:

• File stored in S3 with public access

• $$$ but easy management

• Sharing public content (ISO file) - Current version:

• 4 Nginx servers sharing the same hostname and the same TLS certificate

• Synchronised using BitTorrentSync (Nginx webroot is a BitTorrentSync repository)

• “CDN on a budget”

• New node deployed in 5 minutes automatically (aside from DNS update) with Ansible

Master

ptl.io

ptl.ioptl.io ptl.io

• Sharing private content (ISO file):

• Current version:

• S3 with private files

• The server generates a link valid for X minutes (built-in S3 option)

• Harder to share the content with other people

• Giving access to vulnerable systems:

• Common approach:

• VPN based

• Kind of annoying for me (user management)

• Kind of annoying for customers (setup, speed, connectivity)

• Giving access to vulnerable systems:

• My approach:

• Only web applications

• One reverse proxy with DNS wildcard (????.libcurl.so always resolves to libcurl.so)

• Multiple vulnerable systems running in docker

Attackerlibcurl.so

exercise1

exercise2

http://ptl-1283933-12982021.libcurl.so

exercise3

Attackerlibcurl.so

exercise1

exercise2

http://ptl-invalid-invalid.libcurl.so

exercise3

HTTP 302https://pentesterlab.com/

• Less public security research

• Exploit sales

• Enterprises struggling with dependency hell

• microservices

• docker

Future of web application security

• Better bugs:

• framework have more&more magic

• serialisation

• routing

• parameters handling (not everything is a string)

Future of web application security

louis@pentesterlab.com

Web Application Security - Amazon S3 · •Security engineer during the day • Design review •...

Documents