A beginners guide to application security vulnerabilities and how to identify them.

1. APPSEC 101
BREAK STUFF LIKE A PRO!
WELL, ALSMOST… 
Vladimir Garbuz
HP ALM Security Center of Excellence

2. Intro
 What these sessions are NOT
 What these sessions are

3. Contents
 AppSec testing tools
 Testing stages
 Mapping application’s content
 Input-based vulnerabilities
 Denial of Service
 Client-side controls
 Authentication mechanism
 Session management
 Logic flaws
 Application Server Vulnerabilities
 Final word on process and security RC

4. AppSec testing tools
 the Swiss Army Knife of AppSec – Fiddler
 not just a proxy
 inspect HTTP and HTTPS! (best served in RAW)
 modify and replay
 intercept mid-air
 setup reverse proxy mode
 get request stats
 set filters
 do text encoding
 autoresponder
 scripting in C#

5. AppSec testing tools
 WireShark – when Fiddler doesn’t cut it
 only passive traffic monitoring
 sees everything!
 your browser’s developer console
 socket programming in any language, e.g. Python 
 hacker’s mindset

6. Mapping application’s content
 read the feature specs
 monitor HTTP traffic for all user data entry points
 look at interface differences for different user roles
 discover hidden content
 ViewDocument.jsp  Delete, Upload, Edit, Create, etc.
 lookout for direct server file access (filename specified)
 lookout for verbose error messages
 lookout for debug/god-mode parameters
 lookout for disabled old/future functionality
 lookout for default content - webserver console, files,...

7. Input vulnerabilities

8. Input vulnerabilities: basic checks
 check if server correctly handles unexpected data
 negative indexes and values
 overly large integers
 zero-bytes and other string terminators (e.g. “, #, ;)
 non-existing string specified dates
 look for differences in processing of directly submitted
values AND when parsed from a user uploaded or
controlled file
 relates to ALL input-based vulnerabilities!

9. Input vulnerabilities: SQL injections
 use DB server management software and profiler
 submit ‘ or “ in request, not only “Edit” operations!
 SQLi can be anywhere where DB is accessed based on
user data, in any way!
 monitor for server errors AND the DB log/profiler!
 broken SQL query in DB log, error, etc?.. REPORT!

10. Input vulnerabilities: XSS injections
 general principle – lack of input encoding
 user submitted data is unmodified in HTML page
 from Google XSS guide: "A good test string is
 >'>"><img src=x onerror=alert(0)
 generally, raise an ALARM for any of the following 5:
 < > & " ‘
 within HTML actions and JavaScript code, additionally
 n r ’ ” uXXXX
 sometimes escaping won’t help
 ALARM if URL protocol (http, https) can be manipulated

11. Input vulnerabilities: XSS injections
 reflected XSS
 when a part of URL is reflected back in HTML page
 DON’T forget to URL encode special characters! e.g.:
 http://url.com/1.jsp?param=%3E%3Cscript%3Ealert(1)
%3C%2Fscript%3E
 stored XSS
 a malicious string is added to the server once and
displayed as a part of a page to everyone viewing it
 from POST body, HTTP header, uploaded file, HTML
based server log, etc… MANY vectors!

12. Input vulnerabilities: XSS injections
 DOM XSS
 caused by unsafe JS during runtime inside the browser
 basically, all ALM AngularJS XSS were DOM XSS
 same principles apply (at this low level)
 monitor for special chars appearing in resulting HTML!

13. OK, that’s enough, I’m leaving!

14. Input vulns: HTTP header injection
 for each response header where user data appears
 try inserting carriage-return and line-feed symbols
 the actual symbols! “0d” and “0a” in hex
 if they are returned in server response header unmodified
 ALARM! malicious server headers can be forged or HTTP split!

15. Input vulns: Open redirection
 if the URL data specifies a redirection target
 try modifying or adding the redirection domain, e.g. in
 http://url.com/qcbin/authentication-point/web-ui-
login.jsp?redirect-url=%2Fui%2F
 after that, trigger an event that causes redirection, e.g.
login
 if it redirects to a different domain, ALARM!

16. Input vulns: OS command injection
 if you suspect (or know) some input is passed to
system shell, try adding additional commands. E.g.:
 ; cat /etc/passwd
 http://url.com/ping.jsp?ip=8.8.8.8%3B+cat+%2Fetc%2F
passwd
 if cannot get the response, try long running command
or creating a file to see if the attack was successful
 if this works or something weird happens – ALARM!

17. Input vulns: Path traversal
 a file path or name is directly specified?..
 try adding ../../ in sequences to backtrack out of current
directory and access server file system
 you can create a test file and try accessing it
 also run Process Monitor by Sysinternals to monitor file access
 if you gain access to other files or something fishy
happens – ALARM!

18. Input vulns: XML injections - XXE
 XML External Entities
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" > ] >
<username>&xxe;</username><password>……………
 if no error or file is retruned by server – ALARM!
 if gives an error, but it disappears after you remove
embedded entity and leave only declaration, ALARM!
 <username>blabla</username>

19. Input vulns: XML injections - DoS
 Recursive “billion laughs” attack
<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ELEMENT lolz (#PCDATA)>
<!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<username>&lol9;</username><password>……………

20. Denial of Service

21. Denial of Service
 API request flooding
 check if server correctly handles unexpected data
 oversized data
 zero-bytes in input
 XML “billion laughs” attack or XXE of a huge file (/dev/random or c:pagefile)
 logic fuckups (sorting)
 unpacking
 recursion
 large low entropy data
 malicious usage of regex, globbing
 asynchronous/heavy functionality invocation
 text instead of number
 ………
 thread/socket exhaustion – e.g. slow HTTP, slow request
 ………

22. Denial of Service

23. Client-side controls: Data transmission
 locate and understand all hidden fields and
parameters in client request
 try to intelligently modify them according to their
name/meaning to pwn the system
 for encoded, obfuscated or badly encrypted data
 decode/decrypt, play with it, encode/encrypt back
and replay to pwn the server
 e.g. ASP.NET ViewState is using base64 encoding, like
 YmFzZTY0IGV4YW1wbGU=

24. Client-side controls: User input
 find all places where client restricts input length or
JavaScript enforces some rules or logic
 always check if the server-side code does the same
 not always a vulnerability, but CAN lead to pwnage
 find all controls that are invisible/disabled for certain
user groups, but visible to others
 record a request such controls send for users who can use
them and replay them with user sessions that can’t
 servers frequently trust client-side to perform permissions
checking, which is… erhm… not very smart 

25. Authentication mechanism

26. Authentication mechanism
 Test password quality
 no/weak rules at registration OR “change password”
 attempt to log in with password variations
 e.g. make a long password and try to log in without the last
char
 change character case of one letter an see if that is successful
 ensure no “default accounts” are present in final release

27. Authentication mechanism
 Test username enumeration
 find ALL locations where the username is submitted, e.g.
primary login, self-registration, password change, logout,
account recovery, etc…
 attempt submitting valid and invalid user names
 check if the server responses differ in ANY way (small
typographic differences, server response time, etc.)
 ALARM on any difference

28. Authentication mechanism
 Test resilience to Password Guessing
 find ALL locations where user credentials are submitted
 e.g. login or badly designed “password change”
 try submitting various passwords for a user
 after ~10 times, enter valid ones
 if all this succeeds – the system is vulnerable, ALARM!

29. Authentication mechanism
 Check for unsafe transmission of credentials:
 in URL
 stored in cookies
 if ever transmitted from server to client
 creds are vulnerable to session, access control and XXS attacks
 should never go over HTTP
 if creds are sent over HTTPS but the login page over HTTP
 MITM attacks can steal creds, ALARM!

30. Authentication mechanism
 Check for insecure storage
 check all logs for credentials
 or their hashes
 check configuration files for clear-text credentials
 check for credentials saving on client-side
 in logs, in browser or client “autocomplete”, etc
 all the points are valid for both client and server side

31. Session Management mechanism
 Check for insecure transmission of Session Tokens
 under HTTPS, check if Secure flag is set for cookies
 verify that HTTP and HTTPS parts of application use
different cookies

32. Session Management mechanism
 Check Cookie scope - Domain
 domain better not be set than set liberally to a domain
 e.g. domain=server.com gives the cookie to subdomains
 Check Cookie scope - Path
 path must include only the webapp for which the cookie is

33. Session Management mechanism
 Check for insecure Session tokens storage
 when in URL – proxy logs, Referer header, screen 
 or visible in some logging mechanisms

34. Logic flaws

35. Logic flaws
 Check for Fail-Open conditions
 whenever the app checks user’s credentials, make a note
of all the request parameters
 for each parameter, try:
 submit an empty string as the value
 remove the name/value pair
 submit very long and very short values
 submit strings instead of numbers, and vice versa
 submit the same named parameter multiple times, with the
same and different values
 notice any unusual behavior? ALARM!

36. Logic flaws
 Check Multistage mechanisms
 a single action is performed via a fixed series of steps?..
 modify the steps to interfere with app’s logic, e.g:
 pass all stages, but in a different sequence
 go directly to each step in turn, and continue the normal
sequence from there
 go through the normal steps repeatedly, skipping each single
step
 be clever and try breaking the multistage process 
 see anything fishy?... ALARM!

37. Logic flaws

38. Application server vulnerabilities
 Check for default content and creds
 google info on default config of your specific server
 try default server admin accounts
 try default management console, UI
 nothing irrelevant to the web-app should be present!

39. Application server vulnerabilities
 Check for dangerous HTTP Methods
 try issuing a TRACE request – shouldn’t work, i.e. shouldn’t
return your request to you
 try issuing an OPTIONS request – shouldn’t work either
 not a vulnerability but may aid attacker, bad practice

40. Process and security RC
 don’t be afraid to bother with questions or something
suspicious – you are our helping hands
 another upside – you’ll definitely learn something new
 report every suspicious instance – even if you couldn’t
write an exploit
 prioritize security RC defects
 nothing high or critical from OWASP Top-10

41. Questions and Discussion