A lecture for a Securing Web Applications class More info: https://samsclass.info/129S/129S_S21.shtml

1. CNIT 129S: Securing
Web Applications
Ch 4: Mapping the Applicatio
n
Sl 56
Updated 2-11-2021

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

3. Enumerating Content and
Functionality

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

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

6. Robots.txt
• Intended to stop
search engine
s
• May guide spiders
to interesting
content

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

8. Limitations of Automatic
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

9. Limitations of Automatic
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

10. Limitations of Automatic
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

11. Limitations of Automatic
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

12. Warning
• Spiders may
fi
nd an administrative page and
click every lin
k
• Delete User, Shut Down Database, Restart
Server...

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

14. Example (Not Logged In)

15. • Note items in
car
t
• "user"
contains only
5 URLs

16. • Login
event
seen in
Burp

17. A

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

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

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

23. Discovering Hidden Content
• 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

24. Discovering Hidden Content
• 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.

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

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

27. Dirb
• Good brute-force spidering tool
• Included in Kali Linux

28. B

29. Inference from Published
Content
• Look for pattern
s
• All subdirectories of "auth" start with a capital
lette
r
• One is "ForgotPassword", so try these

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

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

32. Burp Pro's Content
Discovery

33. Google's Skip
fi
sh
• Vulnerability scanner but main strength is
fi
nding
fi
les and folder
s
• Links Ch 4d, 4e

34. Public Information
• Search engines (and cached content
)
• Web archives such as the Wayback Machin
e
• Posts to forums like Stack Exchange

35. Google Advanced Search

36. Web Server Vulnerabilities
• Some Web servers let you list directory
contents or see raw source cod
e
• Sample and diagnostic scripts may contain
vulnerabilities

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

38. Example

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

40. Map of Functional Paths

41. Discovering Hidden
Parameters
• Try adding "debug=true" to request
s
• Or test, hide, source, etc
.
• Burp Intruder can do this (see Ch 14)

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

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

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

45. Entry Points for User Input

46. RESTful URLs

47. Request Parameters
• Normally, google.com?q=duc
k
• Here are some nonstandard parameter formats

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

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

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

51. C

52. Identifying Server-Side
Technologies

53. Banner Grabbing
• Banners often leak version informatio
n
• Also Web page template
s
• Custom HTTP header
s
• URL query string parameters

54. HTTP Fingerprinting
• httprecon uses
subtle clues to
identify
versions, not
just banner
s
• Link Ch 4h

55. Wappalyzer
• Browser extension

56. File Extensions
• Disclose platform or language

57. Error Messages

58. Error Message

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

60. OpenText
• Vignette is now rebranded as OpenTex
t
• Link Ch 4i

61. Directory Names
• Indicate technology in use

62. Session Tokens

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

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

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

66. httprint
• Not updated since 2005 (link Ch 4j
)
• Alternatives include nmap, Netcraft, and
SHODAN (Link Ch 4k
)
• Also the Wappalyzer Chrome extension

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

68. Identifying Server-Side
Functionality
• .jsp - Java Server Page
s
• OrderBy parameter looks like SQ
L
• isExpired suggests that we could get expired
content by changing this value

69. Identifying Server-Side
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

70. Identifying Server-Side
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

71. Identifying Server-Side
Functionality
• Change action to "edit" or "add
"
• Try viewing other collections by
changing the id number

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

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

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

75. Google Dorks
• Link Ch 4p

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

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

79. Mapping the Attack Surface
• 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

80. Mapping the Attack Surface
• 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

81. Mapping the Attack Surface
• 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

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

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

84. D