Application security 101

APPSEC 101BREAK STUFF LIKE A PRO! WELL, ALSMOST…

Vladimir Garbuz

HP ALM Security Center of Excellence

Intro

What these sessions are NOT

What these sessions are

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


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#


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

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

Input vulnerabilities

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!

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!

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


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!

http://url.com/1.jsp?param=><script>alert(1)</script>


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!

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

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!

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!

http://url.com/qcbin/authentication-point/web-ui-login.jsp?redirect-url=/ui/

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!

http://url.com/ping.jsp?ip=8.8.8.8;+cat+/etc/passwd

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!

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>

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;">








]>

<username>&lol9;</username><password>……………

Denial of Service

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

………

Denial of Service

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=

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


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


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


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!


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!


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

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


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


Check for insecure Session tokens storage

when in URL – proxy logs, Referer header, screen

or visible in some logging mechanisms

Logic flaws

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!

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!

Logic flaws

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!

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

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

Questions and Discussion

Application security 101

Software

Transcript of Application security 101