CNIT 129S Ch 4: Mapping the Application

CNIT 129S: Securing
Web Applications
Ch 4: Mapping the Applicatio
n

Sl 56
Updated 2-11-2021

Mapping
• Enumerate application's content and
functionalit
y

• Some is hidden, requiring guesswork
and luck to discove
r

• Examine every aspect of behavior,
security mechanisms, and technologie
s

• Determine attack surface and
vulnerabilities

Enumerating Content and
Functionality

Web Spiders
• Load web page,
fi
nd all links on i
t

• (into the targeted domain
)

• Load those pages,
fi
nd more link
s

• Continue until no new content is discovered

Web Application Spiders
• Also parse HTML form
s

• Fill in the forms with preset or random values
and submit the
m

• Trying to walk through multistage
functionalit
y

• Can also parse client-side JavaScript to extract
URL
s

• Tool: Zed Attack Prox
y

• WebScarab & CAT seem old and abandoned

Robots.txt
• Intended to stop
search engine
s

• May guide spiders
to interesting
content

Limitations of Automatic
Spidering
• May fail to handle unusual navigation
mechanisms, such as dynamically created
JavaScript menu
s

• So it may miss whole areas of an applicatio
n

• Links buried in compiled client-side objects like
ActiveX or Java may be missed

Spidering
• Forms may have validation checks, such as
user registration form
s

• Email address, telephone number, address,
zip cod
e

• Too complex for most spiders, which use a
single text string for all form
fi
eld
s

• Spider cannot understand the "Invalid" error
messages

Spidering
• Spiders only fetch each URL onc
e

• But applications use forms-based navigation,
in which the same URL may return different
content and function
s

• For example, a bank may implement every
user action with a POST to /account.jsp with
parameters determining the actio
n

• Spiders aren't smart enough to handle that

Spidering
• Some applications place volatile data within
URL
s

• Parameters containing timers or random
number seed
s

• Spider will fetch the same page over and over,
thinking it's ne
w

• May freeze up

Spidering
• Authentication: spider must be able to submit
valid credential
s

• Perhaps using a valid cooki
e

• However, spiders often break the authenticated
session, b
y

• Requesting a logout functio
n

• Submitting invalid input to a sensitive functio
n

• Requesting pages out-of-sequence

Warning
• Spiders may
fi
nd an administrative page and
click every lin
k

• Delete User, Shut Down Database, Restart
Server...

User-Directed Spidering
• More sophisticated and controlled technique
than automated spidering, usually preferabl
e

• User walks through application using a browser
connected to Burp (or another proxy
)

• The proxy collects all requests and responses

• Note items in
car
t

• "user"
contains only
5 URLs

Advantages of

User-Directed Spidering
• User can follow unusual or complex navigation
mechanism
s

• User can enter valid data where neede
d

• User can log in as neede
d

• User can avoid dangerous functionality, such as
deleteUser.jsp

Browser Tools
• Chrome's Developer Tools can show details of
requests and responses within the browse
r

• No proxy neede
d

• Often useful; shows timing as well as content

Discovering Hidden Content
• Finding it requires automated testing, manual
testing, and luc
k

• Testing or debugging features left in applicatio
n

• Different functionality for different categories of
user
s

• Anonymous, authenticated, administrator
s

• Backup copies of live
fi
le
s

• May be non-executable and reveal source
code

• Backup archives that contain snapshot of entire
applicatio
n

• New functionality implemented for testing but
not yet linked from main applicatio
n

• Default functionality in an off-the-shelf
application that has been super
fi
cially hidden
from the user but not remove
d

• Old versions of
fi
les--may still be exploitable

• Con
fi
guration and include
fi
les containing
sensitive data such as database credential
s

• Source
fi
les from which application functions
were compile
d

• Comments in source code; may contain
usernames and passwords, "test this" marks,
and other useful dat
a

• Log
fi
les--may contain valid usernames, session
tokens, etc.

Brute-Force Techniques
• Suppose user-directed spidering
fi
nds the URLs
on the lef
t

• A brute-forcer will try names as shown on the
right

Burp's Brute-Forcer
• Burp's brute-
forcer is very
slow in the
free version

Dirb
• Good brute-force spidering tool

• Included in Kali Linux

Inference from Published
Content
• Look for pattern
s

• All subdirectories of "auth" start with a capital
lette
r

• One is "ForgotPassword", so try these

Other Patterns
• Names may use numbers or date
s

• Check include
fi
les from HTML and JavaScrip
t

• They may be publicly readabl
e

• Comments may include database names, SQL
query string
s

• Java applets and ActiveX controls may contain
sensitive data

More Clues
• Search for temporary
fi
les created by tools and
fi
le editor
s

• .DS_Store
fi
le (a directory index created by Mac
OS X
)

•
fi
le.php-1 created when
fi
le.php is edite
d

• .tmp
fi
les created by many tools

Google's Skip
fi
sh
• Vulnerability scanner but main strength is
fi
nding
fi
les and folder
s

• Links Ch 4d, 4e

Public Information
• Search engines (and cached content
)

• Web archives such as the Wayback Machin
e

• Posts to forums like Stack Exchange

Web Server Vulnerabilities
• Some Web servers let you list directory
contents or see raw source cod
e

• Sample and diagnostic scripts may contain
vulnerabilities

Nikto and Wikto
• Scans servers for known vulnerable
fi
les and
version
s

• Wikto is the Windows versio
n

• Nikto is the Linux versio
n

• Included in Kal
i

• Fast and easy to us
e

• Has false positives like all vulnerability
scanner
s

• Must verify results with manual testing

Functional Paths
• Different from old-fashioned tree-
structured
fi
le syste
m

• Every request goes to the same UR
L

• Parameters specify functio
n

• Very different structure to explore

Discovering Hidden
Parameters
• Try adding "debug=true" to request
s

• Or test, hide, source, etc
.

• Burp Intruder can do this (see Ch 14)

Analyzing the Application
• Key area
s

• Core functionalit
y

• Peripheral behavior: off-site links, error
messages, administrative and logging
functions, and use of redirect
s

• Core security mechanisms: session state,
access control, authenticatio
n

• User registration, password change,
account recovery

Key Areas (continued)
• Everywhere the application processes user-
supplied inpu
t

• URL, query string, POST data, cookie
s

• Client-side technologie
s

• Forms, scripts, thick-client components (Java
applets, ActiveX controls, and Flash), and
cookies

Key Areas (continued)
• Server-side technologie
s

• Static and dynamic pages, request
parameters, SSL, Web server software,
interaction with databases, email systems,
and other back-end components

Request Parameters
• Normally, google.com?q=duc
k

• Here are some nonstandard parameter formats

HTTP Headers
• User-Agent is used to detect small screen
s

• Sometimes to modify content to boost search
engine ranking
s

• May allow XSS and other injection attack
s

• Changing User-Agent may reveal a different
user interface

HTTP Headers
• Applications behind a load balancer or proxy
may use X-Forwarded-For header to identify
sourc
e

• Can be manipulated by attacker to inject content

Out-of-Band Channels
• User data may come in vi
a

• Emai
l

• Publishing content via HTTP from another
server (e.g. WebDAV
)

• IDS that sniffs traf
fi
c and puts it into a
Web applicatio
n

• API interface for non-browser user agents,
such as cell phone apps, and then shares
data with the primary web application

Identifying Server-Side
Technologies

Banner Grabbing
• Banners often leak version informatio
n

• Also Web page template
s

• Custom HTTP header
s

• URL query string parameters

HTTP Fingerprinting
• httprecon uses
subtle clues to
identify
versions, not
just banner
s

• Link Ch 4h

Wappalyzer
• Browser extension

File Extensions
• Disclose platform or language

File Extension Mappings
• Different DLLs may
lead to different
error messages

OpenText
• Vignette is now rebranded as OpenTex
t

• Link Ch 4i

Directory Names
• Indicate technology in use

Third-Party Code
Components
• Add common functionality lik
e

• Shopping cart
s

• Login mechanism
s

• Message board
s

• Open-source or commercia
l

• May contain known vulnerabilities

Hack Steps
1. Identify all entry points for user inpu
t

•URL, query string parameters, POST data,
cookies, HTTP header
s

2. Examine query string format; should be some
variation on name/value pai
r

3. Identify any other channels that allow user-
controllable or third-party data into the app

Hack Steps
4. View HTTP server banner returned by the
app; it may use several different server
s

5. Check for other software identi
fi
ers in
custom HTTP headers or HTML source code

6. Run httprint to
fi
ngerprint the web serve
r

7. Research software versions for
vulnerabilitie
s

8. Review map of URLs to
fi
nd interesting
fi
le
extensions, directories, etc. with clues about
the technologies in use

httprint
• Not updated since 2005 (link Ch 4j
)

• Alternatives include nmap, Netcraft, and
SHODAN (Link Ch 4k
)

• Also the Wappalyzer Chrome extension

Hack Steps
9. Review names of session tokens to identify
technologies being use
d

10. Use lists of common technologies, or Google,
to identify technologies in use, or discover other
websites that use the same technologie
s

11. Google unusual cookie names, scripts, HTTP
headers, etc. If possible, download and install
the software to analyze it and
fi
nd vulnerabilities

Functionality
• .jsp - Java Server Page
s

• OrderBy parameter looks like SQ
L

• isExpired suggests that we could get expired
content by changing this value

Functionality
• .aspx - Active Server Pages (Microsoft
)

• template - seems to be a
fi
lename and loc - looks
like a directory; may be vulnerable to path
traversa
l

• edit - maybe we can change
fi
les if this is tru
e

• ver - perhaps changing this will reveal other
functions to attack

Functionality
• .php - PH
P

• Connecting to an email server, with user-controllable
content in all
fi
eld
s

• May be usable to send email
s

• Any
fi
elds may be vulnerable to email header injection

Functionality
• Change action to "edit" or "add
"

• Try viewing other collections by
changing the id number

Extrapolating Application
Behavior
• An application often behaves consistently
across the range of its functionalit
y

• Because code is re-used or written by the
same developer, or to the same speci
fi
cation
s

• So if your SQL injections are being
fi
ltered out,
try injecting elsewhere to see what
fi
ltering is in
effect

Extrapolating Application
Behavior
• If app obfuscates data, try
fi
nding a place where
a user can enter an obfuscated string and
retrieve the original

• Such as an error messag
e

• Or test systematically-varying values and
deduce the obfuscation scheme

Error Handling
• Some errors may be properly handled and give
little information 
Others may crash and return verbose error
information

Isolate Unique Application
Behavior
• App may use a consistent framework that
prevents attack
s

• Look for extra parts "bolted on" later, which
may not be integrated into the framewor
k

• Debug functions, CAPTCHAs, usage tracking,
third-party cod
e

• Different GUI appearance, parameter naming
conventions, comments in source code

Mapping the Attack Surface
• Client-side validatio
n

• Database interaction -- SQL injectio
n

• File uploading and downloading -- Path
traversal, stored XS
S

• Display of user-supplied data - XS
S

• Dynamic redirects -- Redirection and header
attacks

• Social networking features -- username
enumeration, stored XS
S

• Login -- Username enumeration, weak
passwords, brute-force attack
s

• Multistage login -- Logic
fl
aw
s

• Session state -- Predictable tokens, insecure
token handling

• Access controls -- Horizontal and vertical
privilege escalatio
n

• User impersonation functions -- Privilege
escalatio
n

• Cleartext communications -- Session hijacking,
credential thef
t

• Off-site links -- Leakage of query string
parameters in the Referer heade
r

• Interfaces to external systems -- Shortcuts
handling sessions or access controls

• Error messages -- Information leakag
e

• Email interaction -- Email or command injectio
n

• Native code components or interaction -- Buffer
over
fl
ow
s

• Third-party components -- Known vulnerabilitie
s

• Identi
fi
able Web server -- Common
con
fi
guration errors, known bugs

Example
• /auth contains authentication
functions -- test session handling
and access contro
l

• /core/sitestats -- parameters; try
varying them; try wildcards like
all and * ; PageID contains a path,
try traversa
l

• /home -- authenticated user
content; try horizontal privilege
escalation to see other user's info

Example
• /icons and /images -- static content,
might
fi
nd icons indicating third-
party content, but probably nothing
interesting her
e

• /pub -- RESTful resources under /
pub/media and /pub/user; try
changing the numerical value at the
en
d

• /shop -- online shopping, all items
handled similarly; check logic for
possible exploits

CNIT 129S Ch 4: Mapping the Application

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a CNIT 129S Ch 4: Mapping the Application

Semelhante a CNIT 129S Ch 4: Mapping the Application (20)

Mais de Sam Bowne

Mais de Sam Bowne (20)

Último

Último (20)

CNIT 129S Ch 4: Mapping the Application