This document provides an overview of common web application security vulnerabilities and how to test for them. It covers: 1. Never trusting user input and how HTTP works. 2. Testing for misconfiguration issues, hidden options, forced navigation, mass parameter assignment, CSRF, injection flaws like XSS and SQLi, open redirect, path traversal, and DoS vulnerabilities. 3. Recommending automation tools like Dirbuster and BurpSuite to help find issues, but noting that context is important and automated scanners have limitations. More manual testing is needed.

1. WEB APPSEC 101
Andrii Kudiurov
TeamLead @ SoftSeq

2. About me
- Python programming background
- Current job: Teamlead @ SoftSeq (Web app audits &
certification, embedding Secure SDLC)
- Successfully hacked banking, trading, insurance, security, mailing
providers, etc.

3. Plan
1. Basic knowledge to start
2. Never trust user input. How HTTP works.
3. Misconfiguration
4. Hidden options && forced navigation && mass parameter
assignment
5. CSRF
6. Injection
a. XSS
b. SQLi
c. OS Command injection
7. open redirect
8. path traversal
9. DoS due to application logic errors
10. Basic HOWTO
11. Links
12. Questions

4. What?
- Understanding common bugs that allows
doing something evil =)
- Web app vulnerabilities are based inside the app itself (web appsec !=
pentest)
How?
- There’s a lot of info. I’ve tried to explain vulnerabilities that can be found
by QA during testing routine. See links to get more HOWTO

5. Baseline
- How web app, browser and HTTP works, basic HTML
- Any programming language, including (very)basic JS
Tools
- Browser + FoxyFroxy + BurpSuite
- Google =)

7. Misconfiguration
- Opened ports
- Default or no passwords (e.g. RabbitMQ)
- Backup, .git and other sensitive folders accessible
- Default or unnecessary features enabled
- No pre-authorization to staging/testing environment
- Security headers missing (e.g. iframe is allowed: UI redress aka Clickjacking)
- Bad pseudorandom used for password/key/pin generation
- No “Secure”, “HTTPOnly” cookie flags, allowed subdomains and insecure path
- Using components with known vulnerabilities
- And more…
Good news: automated scanners can find it pretty well.

8. Components with known vulnerabilities
- Remember Equifax? They forgot to update library
- Average small app can have ~ 20-40 dependencies
- Enterprise apps can have over 200 dependencies

9. Components with known vulnerabilities
Basic rule: if there is info that component is vulnerable it doesn’t
matter if you can show how to exploit it. UPDATE! Search
vulnerabilities at https://cve.mite.org or https://nvd.nist.gov/
Try to find some of them automatically (all of them can be found
ONLY manually because of reasons =) )
- Dependency checker (ASP, Java)
- Retire.js (vulnerable forntend libs)

10. Directory
Browsing
Use Dirbuster and/or
burpsuite plugins to
detect

11. Click-jacking AKA UI Redress

12. <form action=”changemail”>
<input name=”email”
value=”myemail@m
ail.com”>
<input type=hidden
name=”id” value=”123”>
<button action=”submit”
value=”save”>
</form>
<script>
//script that checks that user
entered everything correctly and
didn’t modify ID
</script>
HTTP. Recall.

13. User pushes
button to
Save profile
Browser adds
headers, cookies
and
Makes request
POST /save HTTP/1.1
Host: bank.com
Cookies: auth=abcdi848d;
Content-length: 123
Connection: close
email=myemail@mail.com&id=123
HTTP. Recall.

14. User pushes
button to
Save profile
Browser adds
headers, cookies and
Makes request
POST /save HTTP/1.1
Host: bank.com
Cookies: auth=abcdi848d;
Connection: close
email=myemail@mail.com&
id=123
PROXY-SERVER
POST /save HTTP/1.1
Host: bank.com
Cookies: auth=abcdi848d;
Connection: close
email=myemail@mail.com&
id=124

15. <div class=’comment’>
…..
</div>
<button value=”answer”
action=”createAnswer()”>
<div class=’comment’>
…..
</div>
<button value=”answer”
action=”createAnser()”>
<button value=”edit”
action=”editPost()”>

16. Direct object reference examples:
- Yahoo: deleting ~ 1m comments and posts
- Apple: 300k 3rd party developers accounts
- FB, VK, Instagram photos
- Some hackers who tried to f*** fortune 100 companies
but totally blew it by exposing all info for scum emails
- Common anti-automation problem

17. Mass parameter assignment
User input:
email=email@email.com
DB model:
- ID
- Email
- IsBlocked
- Some app controllers may process not user input itself, but a model created
from the input to ease coding routine.
- In this case if no additional anti-forgery measures have been implemented,
it is possible to add additional parameters

18. What does it mean?
- No decision making on frontend pls
- Never trust user input. Consider any user input as harmful.
- Input validation on frontend - for UX, on backend - for decision making

19. More thinking…
- Humans make mistakes
- Developers think how to MAKE, not how to BREAK
- Parts written by several developers can be VERY different (one controller can
be totally secure,
another - totally broken)
- Companies with TOP developers and good security teams still are getting
hacked or reported by whitehats

20. CSRF (Cross site request forgery)
Root problem:
Browser sends cookies automatically for every URL or submitted form.
Exploit:
We can craft a form on a web-site we control and force a user to perform
request with desired parameters to a desired resource
Fix:
Unpredictable anti-CRSF token (as one of the parameters in POST queries)

21. <form action=
”http://bank.com/changemail”
>
<input name=”mail”
value=”hacker@mai
l.com”>
<button id=”x”
action=”submit”></form>
<script>x=document.getEle
mentById(“x”).click()</script>
<form action=”changemail”>
<input name=”mail”
value=”myemail@ma
il.com”>
<button action=”submit”>
</form>

22. XSS: (very) short info
- An ability to inject malicious JavaScript to the legitimate site
- Happens when server sends back user-generated data
without validation and sanitization
- Usually exploited by embedding HTML tags or breaking JS
syntax

23. http://example.com?search=asd”><script>alert(“hacked”)</script>

24. Two simple rules to prevent XSS:
1. All user input that comes back from server should be SANITIZED by
trusted functional (e.g. template engine).
2. NEVER write your own filters. They probably can be hacked.
WHY?
<scr<script>ipt>
<img src=x onerror=’alert(1)’>
<a href=”javascript:alert(1)”>click me</a>

25. <IMG
SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#
101;&#114;&#116;&#40;
&#39;&#88;&#83;&#83;&#39;&#41;>
<IMG SRC="jav&#x09;ascript:alert('XSS');">
<BODY onload!#$%&()*~+-_.,:;?@[/|]^`=alert("XSS")>
<iframe src=http://xss.rocks/scriptlet.html <
<STYLE>li {list-style-image: url("javascript:alert('XSS')");}</STYLE><UL><LI>XSS</br>
<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">
"'}})}}})});alert('hacked'); window.addEventListener('load', function() { new Vue({ methods:{
filter:function(){$.ajax({data:{a:'"
Own filter = bad idea

26. SQL Injection
- Happens when user input is passed to SQL query so it can be modified.
For example, user is trying to access some user item:
SELECT * FROM items WHERE itemname = 'secret_unique_id';
- If we have control over ‘secret_unique_id’, we can submit special syntax
and receive all items.
Like:
SELECT * FROM items WHERE itemname = 'secret_unique_id' OR
'a'='a';

27. SQL Injection
- Not very common in the new projects
- Exists because user input is not validated and for some reason raw SQL
queries are still used.
- Easier to search in the source code rather than blackbox

28. SQL Injection hints
- Easily avoided if ORM/parameterized queries are used
- Some ORM-parameters can be still exploited, read specs!
- Check stored procedures!
- Even if you think everybody is writing in a secure manner, someone
probably have used raw SQL to execute a complex query

29. OS Command Injection
- Accepting user input inside OS command invocation
- Can be easily found in the source code by keywords
Cases:
- Proto and video modification (imagemagic, ffmpeg)
- Operations with files, folders, systems (e.g. some deploy platforms)

30. Example 1:
Old-school zero-byte
www.example.com/get-the-page%00
DOS via application logic errors

31. Example 2: Modern world
www.cute-images.com/image/cute_puppy.png?width=100&height=100
www.cute-
images.com/image/save/resize/cute_puppy.png?width=100&height=100
….what if?
www.cute-
images.com/image/cute_puppy.png?width=2147483647&height=2147483647
www.cute-
images.com/image/save/resize/cute_puppy.png?width=2147483647&height=21
47483647
DOS via application logic errors

32. Open redirect.
Case:
1. User tries to reach URL, but he is not logged in.
2. For better UX, user should be redirected to login page and after — back to the
page he requested
Example:
User tries to reach http://example.com/page12134
User is redirected to http://example.com/login?redirect=/page1234
But what if we make user to follow link like this:
http://example.com/login?redirect=http://exampIe.com

34. Path traversal
Usually happens when user input is feeded directly in file path
parameter
e.g. f = open(“FOLDER_NAME” + user_input_file, “r”)

35. Basic “How to test”
BlackBox:
- Check how application handles unexpected data (single/double quotes, <>,
%0a%0d%00, etc.)
- Simple XSS test: '';!--"<XSS>=&{()}
- Simple SQLi test: 1' or '1' = '1
- Path traversal ../../../../../../../etc/passwd (or other known file)
- directory browsing and open folders DIRBUSTER (careful, can DOS the server)
- CSRF: check if anti-csrf token is present AND it’s required
- OS command injection: if something looks like shell command - try to insert
another
Desired result: unpredicted behavior or errors.

36. WhiteBox (access to source code)
Easy:
1. Find OWASP Code review guide
2. Find desired language and search for keywords, review them.
3. For frontend - search for .innerHTML, eval(), $.html (there is more. Search for
your framework)

37. Automation doesn’t work (as good as expected) because
CONTEXT MATTERS.
Automated solutions find
- hundreds of false-positives
- Can’t find not obvious vulnerabilities
But:
- Better than nothing
- Can work better for some projects
- Detects misconfiguration
- Can be tweaked and proxied to perform better for you

38. Info and literature:
1. GOOGLE
2. Our appsec knowledge checklist: link
a. Some playgrounds: p.5-10
3. OWASP ASVS (standard), OWASP Testing Guide at https://owasp.org
4. Web Application hacker’s handbook

39. Thank you!
Any questions?
FB: Andrii Kudiurov