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

Size: px

Start display at page:

Download "Application Security Testing. Erez Metula (CISSP), Founder Application Security Expert ErezMetula@AppSec.co.il"

Emily Bryant
8 years ago
Views:

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

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

outside, as an attacker Whitebox usually means performing design code reviews,

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. Commonly known as black box testing

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 Repeatable and can be batched

code or script to execute the test cases Useful when results are

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 Is finding everything with a tool possible? 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 Logical Vulnerabilities

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

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

in theory, as tools mature) Technical Vulnerabilities examples Lack of

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.

conceptually wrong Logical Vulnerabilities examples Spend deposit before deposit funds are

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 See the Raw Data sent and received

12 Network proxy - Demo

13 HTTP Proxy - DEMO Request Response

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 Example 2 - Money transfer/withdraw becomes a deposit

Identity Permissions Path and file names Etc Example 1 - Changing cookie values

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

reference Locate interesting parameters in the request Tamper with the

16 Cross-Site Scripting (XSS) Web browsers execute code sent from websites HTML Javascript Flash, etc. send malicious code to other users the attacker is using the website to forward an attack!

17 Cross-Site Scripting (XSS).. out.writeln("<h1>hello " +username + "</h1>");.. <html>... <h1>hello David</h1>... </html> <html>... <h1>hello <script>malicious_code!</script></h1>... </html>

.. <h1>hello David</h1>... </html> http://c1-m0.victim-site.com/xss/xss.asp?

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: Tip: Use RSnake s XSS cheat sheet

19 XSS tools XSS specific XSS me (FF add-on) Web application scanners Burp W3af

20 XSS me Demo

21 SQL Injection Developer concate SQL statements string sql = "select * from Users where user ='" + User.Text + "' and pwd='" + Password.Text + "'" Hacker types: or 1=1 -- string sql = "select * from Users where user =' ' or 1=1 --' and pwd=''" Result is the first database entry, maybe the Admin!

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 W3af

24 SQL me

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 If you ve succeeded - you ve found a problem

27 Information Leakage and Improper Error Handling 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)

28 l Full path names revealed l Table Name l Field Name l Database Name

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

Common Mistake backup files Downloadable extensions http://c1-m0.victim-site.com/hacmebank_v2_ws/web.config.bak File.aspx.old File.

32 Common Mistake backup files Downloadable extensions 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 may contain powerful functionality

34 Common Mistake compressed archives DEMO

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 Path traversal 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 But the user can get out of the current directory..

37 Canonicalization Another example - String comparison canonicalization evasion The user is not allowed to access the NotAllowed.txt if (filename.equals("notallowed.txt"){//abort the request} DirectoryTraversal/DownloadHandler.ashx?filename=NotAllowed.txt Using a canonical form, it can be accesed using a different name DownloadHandler.ashx?filename=NotAll~1.txt DownloadHandler.ashx?filename=NotAllowed.txt. DownloadHandler.ashx?filename=..\content\NotAllowed.txt DownloadHandler.ashx?filename=NoSuchDir\..\NotAllowed.txt

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); Legitimate use: // read & print the file page=source-viewer.php&php_file_name=catch.php But the user can get out of the base directory.. page=source-viewer.php&php_file_name=catch.php

39 Failure to Restrict URL Access 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: 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 If you can access the page, you ve found a problem

41 Command injection 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 < > & Windows / Unix commands (dir, ls, ipconfig, etc..)

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 Questions?

46 Thank You!

Creating Stronger, Safer, Web Facing Code. JPL IT Security Mary Rivera June 17, 2011

Creating Stronger, Safer, Web Facing Code JPL IT Security Mary Rivera June 17, 2011 Agenda Evolving Threats Operating System Application User Generated Content JPL s Application Security Program Securing