Save 37% off PRO during our Black Friday Sale! »

Your web application seen from the hell's kitchen

857c770ccb0a8e869994f663f09b22ec?s=47 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


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

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

    Blogger at • Husband && Dad • Taekwon-do ITF martial artist • Twitter hashtag for today’s topic: #appsec_hk
  3. Section 1 Alone in the darkness

  4. 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
  5. The Internet As normal people think it is…

  6. The Internet As it really is… a place full of

    opportunities, to make business and to be ruined by villains
  7. 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)
  8. Breaches in 2015 (US) ITRCBreachStatsReportSummary2015.pdf

  9. Very popular breach in 2015

  10. Even crowfunders got hacked

  11. Some Italian breaches in 2015 sources:

  12. “The” Italian breach in 2015

  13. They happens every… single… day

  14. What attackers want - 1 Other people identity Servers Servers

    picture courtesy by: Matthew Musgrove ( Bot picture courtesy by: Jenn and Tony Bot ( Botnets
  15. What attackers want - 2 Hacktivism Guy fawkes mask picture

    courtesy by: Thierry Hermann ( Newspaper vendor picture courtesy by: Nathan Gibbs ( Boycott corporations Money Bitcoin guy picture courtesy by: scottks (
  16. The Owasp Top 10 (2013 edition)

  17. 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?
  18. 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…
  19. 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
  20. Runtime risks • Cross site scripting - reflected - stored

    - DOM Based • SQL Injections • Vulnerable third party components (OS, system daemons, libraries, …)
  21. Section 2 Dangers from strangers

  22. 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.
  23. This is not an ethical hacking class!!! But I want

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

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

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

    project made to train developers about appsec
  27. 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
  28. 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) - technologies/details/cm-wordpress/all/ all • Vulnerabilities for plugins and themes out almost everyday
  29. Attacking servers

  30. Step 0. Information gathering • Detect open ports and listening

    services • Detect Operating System
  31. Step 1. Vulnerability assessment • Use Google to find vulns

    - vsftpd - smb - nfs - Unreal ircd • Use tools (€€€!) - Nexpose - Nessus - Qualys
  32. Step 2. Exploit / OS It’s showtime

  33. Step 2. Exploit / OS (daemons) It’s showtime

  34. Attacking web applications

  35. 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)
  36. Step 1. Recognisance • Detect web server and underlying framework

    • SSL Certificate check • URLs enumeration • Website crawling
  37. Step 2. Exploit It’s showtime (image courtesy by:

  38. Section 3 Heal the world, make a better place

  39. 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
  40. 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
  41. Heal your web exposure • Lockdown your web server config

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

    code review • Follow best practices
  43. 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
  44. Deploy, the sane way • Double check ORM / Warden

    configuration • Provide securely generated seeds • Use staging and make regression tests • Use capistrano-like tools • if == 5 then sleep(172800); // 2 days! :-)
  45. If you’re thinking “I know, but I’m always late”, then

    “automate it”
  46. Remember: you must be authorised Please, be nice Please Really

  47. But be aware of ‘revenge of the .git’ It’s showtime

  48. 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
  49. Review the code: dawnscanner It’s showtime

  50. Review the code: brakeman It’s showtime (the important rule is

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

    web application penetration test but I must deploy today… oh… it’s showtime again
  52. 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
  53. So let’s be realistic even #appsec guys have an heart

  54. 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
  55. Let’s use [T|B]DD • Write your own security stories •

    Ask you neighbourhood #appsec guy to write them • Use something already prepared (http:// getstarted.html) • Integrate your stories in your testing workout • You just scored a A- in your security class
  56. Use [T|B]DD It’s showtime

  57. Some links • This is the slide everybody loves •

    A comprehensive list will be available at
  58. Questions?

  59. Thanks! @thesp0nge