Application Security Testing. Erez Metula (CISSP), Founder Application Security Expert

(1)

Application Security Testing

Erez Metula (CISSP), Founder

Application Security Expert

[email protected]

(2)

• The most common security vulnerabilities you should test for

• Understanding the problems • How to test

• Tools

• Technical VS. Logical security issues • Whitebox VS. Blackbox testing

• What to look for

(3)

BlackBox Vs. Whitebox testing

• Blackbox usually means testing the application from the outside, as an attacker

• Whitebox usually means performing design code reviews, from “the inside”

• Whitebox is considered superior to blackbox • But it is not always possible

• There are problems which are more visible with a blackbox testing

(4)

Penetration Testing

• Test a running application remotely, without knowing the inner workings of the application itself to find security vulnerabilities. • The tester acts like a attacker and attempts to find and exploit

vulnerabilities.

(5)

Testing Methods

• Manual testing

• Manually execute the test cases

• Often useful for user interface testing • Automated testing

• Create code or script to execute the test cases • Useful when results are pass or fail

• Useful for regression testing

(6)

Automated scanning tools

• Scanner tools perform automatic testing • Some examples

• Open source

• Burp scanner

• Paros proxy scan module • W3af

• commercial • Acunetix • Appscan • Webinspect

(7)

But isn’t there a tool able to find out

all security vulnerabilities?

(8)

with a tool possible?

everything

Is finding

No!

There are things that we can automate and things that we cannot automate.

There are issues that are easy to automate reliable detection and issues that are not

There are two main types of application security issues: • Technical Vulnerabilities

(9)

Technical Vulnerabilities

• Technical Vulnerabilities

• Usually about Data Handling

• Can be tested fairly effectively by automated tools (at least, in theory, as tools mature)

• Technical Vulnerabilities examples • Lack of Input Validation

• XSS

• SQL Injection

• Parameter Tampering • Buffer overflows

(10)

Logical Vulnerabilities

• Deals with issues allowed by design, but not foreseen by the designers (or understood to be a risk)

• A functionally is working without any bugs, but doing something conceptually wrong

• Logical Vulnerabilities examples

• Spend deposit before deposit funds are validated (B/L) • Flow problems - jumping from one page to another

• Negative values performing the opposite operation • Etc.

(11)

Proxy tools

• Proxy tools use to watch and edit request and responses • The main usage is to:

• Manipulate with the page parameters • Bypass client restrictions

(12)

(13)

HTTP Proxy - DEMO

Request

(14)

Parameter manipulation

• Closely related to indirect object reference

• The user tampers with some information that controls the behavior of the application

• Identity

• Permissions

• Path and file names • Etc

• Example 1 - Changing cookie values and becoming the application administrator

(15)

Parameter manipulation testing

approach

• Suggested testing type – manual

• Suggested to be combined with a proxy

• Very similar to direct object reference

• Locate interesting parameters in the request

• Tamper with the values

• GET (part of the URL) – you can use the browser

• POST – you need a proxy

(16)

Cross-Site Scripting (XSS)

• Web browsers execute code sent from websites

• HTML

• Javascript

• Flash, etc.

• send malicious code to other users

(17)

Cross-Site Scripting (XSS)

http://c1-m0.victim-site.com/xss/xss.asp?username=David <html> ... <h1>Hello David</h1> ... </html> <html> ... <h1>Hello David</h1> ... </html> http://c1-m0.victim-site.com/xss/xss.asp?username=<script>malicious_code!</script> <html> ... <h1>Hello <script>malicious_code!</script></h1> ... </html> <html> ... <h1>Hello <script>malicious_code!</script></h1> ... </html> .. out.writeln("<h1>Hello " +username + "</h1>"); .. .. out.writeln("<h1>Hello " +username + "</h1>"); ..

(18)

XSS testing approach

Suggested testing type – manual and automatic

For each element (e) in the page

• Enter:

<script>alert(“xss”);</script>

• If you get an alert popup than a XSS is detected

• Demo:

•

http://c1-m0.victim-site.com/xss/xss.asp?username=David

• Tip: Use RSnake’s XSS cheat sheet

(19)

XSS tools

• XSS specific

• XSS me (FF add-on)

• Web application scanners • Burp

(20)

XSS me

Demo

(21)

Developer concate SQL statements

Hacker types: ‘ or 1=1

--Result is the first database entry, maybe the Admin!

string sql = "select * from Users where

user ='" + User.Text + "'

and pwd='" + Password.Text + "'"

string sql = "select * from Users where

user =' ' or 1=1 --' and pwd=''"

(22)

SQL Injection testing approach

Suggested testing type – manual and automatic

For each element (e) in the page

• Enter:

‘

• If you get an SQL error you’ve found an injection

• Enter: ‘ or 1=1—

• If the application behave different than what it’s

supposed to do (example: bypass login) you’ve

found an injection

• Demo:

(23)

SQL injection tools

• Sql injection specific

• SQLme (FireFox add-on) • PRIAMOS

• SQLmap

• Web application scanners • Burp

(24)

(25)

Malicious File Execution

• Code can be injected as server side executable file

• jsp,asp,php,aspx,etc..

• Especially dangerous when having upload functionality,

in case the files are stored inside the web root folder

• Example:

• Attacker upload a jsp file:

(26)

Malicious File Execution testing

approach

• Suggested testing type - manual

• Locate all the upload pages on the application

• Create a dummy page with the same extension the application has, and upload it

• Some examples:

• .NET: backdoor.aspx • Java: backdoor.jsp • PHP: backdoor.php

• Try to access the URL of this page

(27)

• Errors occur in web applications all the time

• Out of memory, too many users, timeout, db failure

• Authentication failure, access control failure, bad input

• Error details reveal enormous information regarding the

internal system

• Stack traces

• Debug messages

• OS error code (file location on disk)

Information Leakage and Improper Error

Handling

(28)

l

Full path

names

revealed

l

Field Name

l

Table Name

l

Database

Name

(29)

(30)

Errors testing approach

• Suggested testing type – manual & automatic

• Enter data that the application should not accept

• Examples

• A string when a number is expected

• Negative values

• Real numbers (fractions)

• Special signs – ‘ < > “ &

• Example

•

(31)

File extensions handling

• Execute extensions

• Extensions without a handler defined in the web server get streamed out to the client as-is

(32)

Common Mistake – backup files

• Downloadable extensions • http://c1-m0.victim-site.com/HacmeBank_v2_WS/Web.config.bak • File.aspx.old • File.aspx.bak • File.aspx_ • Etc..

• may disclose sensitive information • Source code

• database credentials • hidden content

• absolute file paths • etc.

(33)

Common Mistake – old versions

• Here we’re talking about older version of the file, which can be executed

• File extension is preserved • Examples • File_old.aspx • File.old.aspx • File_bak.aspx • File_bkp.aspx • Etc..

• May contain vulnerabilities that have been fixed in more recent versions

(34)

Common

Mistake – compressed archives

• DEMO • http://c1-m0.victim-site.com/HacmeBank_v2_WS/ • http://c1-m0.victim-site.com/HacmeBank_v2_WS/HacmeBank_v2_Ws.zip • http://c1-m0.victim-site.com/HacmeBank_v2_WS/HacmeBank_v2_Ws.tar • http://c1-m0.victim-site.com/HacmeBank_v2_WS/HacmeBank_v2_Ws.rar • http://c1-m0.victim-site.com/HacmeBank_v2_WS/App_Data.zip

(35)

Look for leftovers..

• Any combination of: • test.<ext> • temp.<ext> • debug.<ext> • foo.<ext> • Includes • page.inc • page.conf • page.config

• Files left in public directories

• ToDo.txt

• Changelogs

• Older versions and test pages

• page.asp.bak / page.bak • page.asp.org / page.org • page.asp.old / page.old

(36)

• The following demo shows an innocent looking page, letting the user to show the source code of files from the current directory.

• Code:

$phpfilename = $_REQUEST["php_file_name"]; // get file name from request highlight_file($phpfilename); // read & print the file

•

http://c0-m0.victim- site.com/mutillidae/index.php?page=source-viewer.php&php_file_name=catch.php

• But the user can get out of the current directory.. •

http://c0-m0.victim-

site.com/mutillidae/index.php?page=source-viewer.php&php_file_name=../../../../../etc/passwd

(37)

• Another example - String comparison canonicalization evasion • The user is not allowed to access the “NotAllowed.txt”

if (filename.Equals("NotAllowed.txt"){//abort the request}

http://c1-m0.victim-site.com/InputValidationFlaws/

DirectoryTraversal/DownloadHandler.ashx?filename=NotAllowed.txt

• Using a canonical form, it can be accesed using a different name

http://c1-m0.victim-site.com/InputValidationFlaws/DirectoryTraversal/ DownloadHandler.ashx?filename=NotAll~1.txt http://c1-m0.victim-site.com/InputValidationFlaws/DirectoryTraversal/ DownloadHandler.ashx?filename=NotAllowed.txt. http://c1-m0.victim-site.com/InputValidationFlaws/DirectoryTraversal/ DownloadHandler.ashx?filename=..\content\NotAllowed.txt http://c1-m0.victim-site.com/InputValidationFlaws/DirectoryTraversal/ DownloadHandler.ashx?filename=NoSuchDir\..\NotAllowed.txt

Canonicalization

(38)

Canonicalization demo

• The following demo shows an innocent looking page, letting the user to show the source code of files from the current directory.

• Code:

$phpfilename = $_REQUEST["php_file_name"]; // get file name from request highlight_file($phpfilename); // read & print the file

• Legitimate use:

http://c0-m0.victim-site.com/mutillidae/index.php? page=source-viewer.php&php_file_name=catch.php

• But the user can get out of the base directory..

http://c0-m0.victim-site.com/mutillidae/index.php? page=source-viewer.php&php_file_name=catch.php

(39)

• Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users.

• Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly

• Example:

•

http://c1-m0.victim-site.com/HacmeBank_v2_Website/aspx/Main.aspx?function=ad min\Sql_Query

(40)

Restricted access testing

• Use 2 accounts with different permissions • Example: regular user & administrator

• Using the administrator user account, open a restricted page • Copy the URL

• Open a different browser using the regular user account • Paste the URL

(41)

• Command injection occurs when you concatenate user input with some command:

• int main(char* argc, char** argv) {

char cmd[CMD_MAX] = "/usr/bin/cat "; strcat(cmd, argv[1]);

system(cmd); }

If the user enters: somefile; rm –rf /

Now the OS will run: /usr/bin/cat somefile ; rm –rf /

(42)

Demo

• Command injection

(43)

Command injection testing approach

• Suggested testing type – manual & automatic

• Enter data that the application should not accept

• Examples

• Special signs – ‘ < > “ &

(44)

Summary

• There are many applications out there containing security vulnerabilities

• Security bug = loss of money, time, life, etc.. • Most QA test cases do not cover security testing

• Testing that security mechanisms “work” is not considered security testing

• Use your knowledge and tools to test for security vulnerabilities

• You should understand the problems before going into testing them

• Try to test the applications as soon as possible, preferably during the SDLC

(45)

(46)