1.
APPSEC 101
BREAK STUFF LIKE A PRO!
WELL, ALSMOST… 
Vladimir Garbuz

2.
Contents
 AppSec testing tools
 Testing stages
 Mapping application’s content
 Input-based vulnerabilities
 Denial of Service
 Client-side controls

3.
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
 scripting in C#

4.
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

5.
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
 record a request such controls send for users who
can use them and replay them with user sessions
that can’t
 discover hidden content
 ViewDocument.jsp  Delete, Upload, Edit, Create,
etc.
 lookout for direct server file access (filename

6.
Input vulnerabilities

7.
Input vulnerabilities: basic
checks
 check if server correctly handles unexpected
data
 negative indexes and values
 overly large integers
 zero-bytes
 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!

8.
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!

9.
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

10.
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!

11.
Input vulnerabilities: XSS
injections
 DOM XSS
 caused by unsafe JS during runtime inside the
browser
 same principles apply (at this low level)
 monitor for special chars appearing in resulting
HTML!
 example:
http://url.com/page.jsp?param=value#section1%3E
%3Cscript%3Ealert(1)%3C%2Fscript%3E

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

13.
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!
 Example evil URL:
http://url.com/page.jsp?contentType=text/html%0d%0aE
vilHeader%3A%20blabla
 Example vulnerable server response:
HTTP/1.1 200 OK
Content-Type: text/html
EvilHeader: blabla

14.
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:///etc/shadow" > ] >
<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!

15.
Input vulnerabilities

16.
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!

17.
Denial of Service

18.
Denial of Service
 check if server correctly handles unexpected
data
 zero-bytes in input
 XML “billion laughs” attack or XXE of a huge file
(/dev/random or c:pagefile)
 unpacking large low entropy data
 regex, globbing and other text processing
functionality
 asynchronous/heavy functionality invocation
 API request flooding
 slow HTTP - thread/socket exhaustion

19.
XML Billion laughs attack - 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.
Questions and Discussion
Email: vladimir.garbuz@owasp.org
Skype: vigarbuz