Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Your web application seen from the hell's kitchen

Paolo Perego
November 13, 2015

Your web application seen from the hell's kitchen

This is the deck for the talk I gave at Rubyday 2015 in Turin.
Attackers see your web application in a very different way, it's not product, it's a target.

Paolo Perego

November 13, 2015

More Decks by Paolo Perego

Other Decks in Technology


  1. Your web application seen from the Hell’s Kitchen RubyDay.it -

    Torino, November 13 2015 < CodiceInsicuro />
  2. $ whoami • Application Security Specialist • Ruby lover •

    Blogger at https://codiceinsicuro.it • Husband && Dad • Taekwon-do ITF martial artist • Twitter hashtag for today’s topic: #appsec_hk
  3. Section objectives • Understand the risk of exposing a poor

    designed web application • See some real world break-ins • Knows what SQLinj, XSS, exploits, authentication bypass, user enumeration mean
  4. The Internet As it really is… a place full of

    opportunities, to make business and to be ruined by villains
  5. Attackers are everywhere • Villains (want your databases, want to

    takeover your servers, want you to stop to work) • Bots (the same as villains but fully automated) • Malware (wants to spread itself mostly to hijack your workstation and steal data) • Activists (the same as villains but philosophy driven)
  6. What attackers want - 1 Other people identity Servers Servers

    picture courtesy by: Matthew Musgrove (https://flic.kr/p/6xsbxQ) Bot picture courtesy by: Jenn and Tony Bot (https://flic.kr/p/6Bk6p8) Botnets
  7. What attackers want - 2 Hacktivism Guy fawkes mask picture

    courtesy by: Thierry Hermann (https://flic.kr/p/bmUQJw) Newspaper vendor picture courtesy by: Nathan Gibbs (https://flic.kr/p/deNep) Boycott corporations Money Bitcoin guy picture courtesy by: scottks (https://flic.kr/p/j1XXSa)
  8. Hosting risks • Cloud is the new black • Shared

    servers are dangerous • Outsourced security - you’re a number, not a priority - are hosting providers security aware? - do they make VA and WAPT on regular basis? - do they have Web Application Firewalls?
  9. OS Based risks • Poorly configured daemons • Missing patches

    (security || all) • Non hardened accounts • Missing basic firewall protection • Advanced web application firewall protection is required too…
  10. Authentication risks • Information leakage due to SSL poorly configured

    • User enumeration • Weak credentials. Password policy, anyone? • Authentication bypass due to poor session management - Session fixation
  11. Runtime risks • Cross site scripting - reflected - stored

    - DOM Based • SQL Injections • Vulnerable third party components (OS, system daemons, libraries, …)
  12. Section objectives • Learn more about security tools (both commercial

    than opensource… but we love most the latter) • See how some very common attacks can be carried on.
  13. This is not an ethical hacking class!!! But I want

    to show you some funny stuff :-)
  14. Victim 1: The ancient server • Ubuntu 8.04 based •

    Heavily misconfigured • Made to be exploited • “Do they still exists?” - “Yes!”
  15. Victim 2: Cyclone Transfer • Rails 3.2 web app •

    It brake a lot of code stilling guide • Serious vulnerabilities inside
  16. Victim 3: Railsgoat • Rails 4 web application • Owasp

    project made to train developers about appsec
  17. Victim 4: A broken Sinatra app • Sinatra based app

    • The “Hello World!” of the XSS example • Here to demonstrate how to use BDD and a security story • … and because I love Sinatra
  18. Bonus Victim: Old WordPress • It’s PHP, everybody here is

    happy to break it! • Empower 25% of the Internet websites out there (58,7% of websites with a CMS installed) - http://w3techs.com/ technologies/details/cm-wordpress/all/ all • Vulnerabilities for plugins and themes out almost everyday
  19. Step 1. Vulnerability assessment • Use Google to find vulns

    - vsftpd - smb - nfs - Unreal ircd • Use tools (€€€!) - Nexpose - Nessus - Qualys
  20. Step 0. Information gathering • Google dorks • Netcraft services

    • Venerable whois • “ip:” query courtesy by Bing (today we work offline, those techniques won’t be applicable)
  21. Step 1. Recognisance • Detect web server and underlying framework

    • SSL Certificate check • URLs enumeration • Website crawling
  22. Section objectives • Harden your server and keep it updated

    automagically • Setup some basic ipfilter rules • Setup a web application firewall with nginx and mod_security • Use code review to heal our source code from vulnerabilities • Learn some tips to write safe code starting from today
  23. Heal your basement • Tune your OS with automatic security

    patching • Install an intrusion detection software (tripwire or aide) • Setup firewalling with iptables • Harden your configuration - install libpam-cracklib - setup password aging
  24. Heal your web exposure • Lockdown your web server config

    • Install and tune mod_security • Do a very basic penetration test before deploy
  25. Heal your code • Deploy the safe manner • Use

    code review • Follow best practices
  26. Deploy, the insane way • Not using a versioning system

    at all • Using SMB provided, cut & paste facilities • Copying all repository content via bulk command • rsync
  27. Deploy, the sane way • Double check ORM / Warden

    configuration • Provide securely generated seeds • Use staging and make regression tests • Use capistrano-like tools • if DateTime.now.wday == 5 then sleep(172800); // 2 days! :-)
  28. Use code review tools • Choose the tool you’re more

    comfortable with • Integrate in your rake test strategy • Some KPI you must have: - some stats about your code (LOC/ comment density, …) - vulnerability in third party dependencies - warning about bad programming habits
  29. Review the code: brakeman It’s showtime (the important rule is

    not to trust a single tool… trust only your brain)
  30. What about dynamic testing? …or the time I wanted a

    web application penetration test but I must deploy today… oh… it’s showtime again
  31. Testing software is good but… • Customers don’t give enough

    time - strict timeframes - not clear specs (remember, ideally it’s up to the customer to write BDD scenarios) • We’re not trained to - school teach us we must deploy a code that is working - school doesn’t teach us how to write good test lists
  32. So let’s be realistic • We must test out software

    • But we don’t have time, we have to ship code • So testing must be - automatic - generic - fast - easy to consume • This way we can iterate over development - testing - shipment
  33. Let’s use [T|B]DD • Write your own security stories •

    Ask you neighbourhood #appsec guy to write them • Use something already prepared (http:// www.continuumsecurity.net/bdd- getstarted.html) • Integrate your stories in your testing workout • You just scored a A- in your security class
  34. Some links • This is the slide everybody loves •

    A comprehensive list will be available at https://codiceinsicuro.it/useful_links.txt