1. Security Testing
Stefana Botezatu
May, 2013

2. Security Testing
•Generalities
•OWASP - Top Ten Vulnerabilities

3. Generalities
• What is Security Testing & Why is needed?
• When & What to test?
• Types of Security Testing
• Principles of Security Testing
• Security Testing Techniques

4. All begin from here …

5. What can cause trouble?

6. What is Security Testing & Why is needed?
• Security Testing is the process to determine that an Information
System protects data and maintains functionality as intended.
• Security Testing is needed:
 To ensure Input Data Validation
 To ensure Control on Internal Processing
 To ensure Message Integrity
 To ensure Output Data Validation

7. When to test?
• To prevent security bugs from appearing in production applications,
SDLC should be improved to include security on each of its phases.

8. What to test?
• A common mistake when testing for security is to conduct tests related only
to technology or software itself.
• An effective testing program should test:
 People - to ensure that there is adequate education and awareness;
 Process - to ensure there are adequate policies and standards and
people know how to follow the policies;
 Technology - to ensure that the process has been effective in it’s
implementation.

9. Types of Security Testing
• Security Auditing
 Direct inspection of the application developed and Operating System
 Code Walk-through
• Security Scanning
 Scanning and verification of system and applications
 Auditors inspect and try to find weaknesses in Operating Systems, applications,
network(s)
• Vulnerability Scanning
 Scanning app for all known vulnerabilities
 Generally performed using vulnerability scanning software

10. Types of Security Testing
• Risk Assessment
 Interviews, discussions, analysis around same thing
 Helps in finding out and preparing possible back-up plan for any type of potential
risk
• Ethical Hacking
 Forced intrusion of an external element into the system and application under test
• Posture Assessment and Security Testing
 Combination of Security Scanning, Risk Assessment and Ethical Hacking
• Penetration Testing
 Tester that tries to forcibly access and enter the application under test
 Using of other applications or combinations of loopholes present in application
under test

11. Principles of Security Testing
• There is no Silver Bullet
• Think Strategically, Not Tactically
• SDLC is the King
• Test Early and Test Often
• Understand the Scope of Security
• Develop the Right Mindset
TIME
RISK
LEVEL
Vulnerability is
made public
A security
vulnerability is
discovered
Vulnerability is
known to the
vendor
Vendor notifies
its clients
(sometime)
Security
tools are
updated
A patch is
published
Existence
of patch is
widely
known
Patch is
installed
in all
systems
affected

12. Principles of Security Testing
• Understand the Subject
• Use the Right Tool
• The Devil is in Details
• Use Source Code when available
• Develop Metrics
• Document the Test Results

13. Security Testing Techniques
• Manual Inspections & Reviews
• Threat Modeling
• Balanced Approach

14. OWASP – Top Ten Vulnerabilities
• OWASP – Open Web Application Security Project
• Is a not-for-profit worldwide charitable organization
focused on improving the security of application software
• More info: http://www.owasp.org

15. OWASP – Top Ten Vulnerabilities

16. A1.Injection

17. What is a SQL Injection?
• A SQL injection attack consists of insertion or "injection" of a SQL query via the input
data from the client to the application.
• Any user-controlled parameter that gets processed by the application might be hiding
vulnerability.
This includes:
 Application parameters in query strings (e.g., GET requests)
 Application parameters included as part of the body of a POST request
 Browser-related information (e.g., user-agent, referrer)
 Host-related information (e.g., host name, IP)
 Session-related information (e.g., user ID, cookies)

18. What is a SQL Injection?
• Classes of SQL injection
 Inband: data is extracted using the same channel that is used to
inject the SQL code. This is the most straightforward kind of
attack, in which the retrieved data is presented directly in the
application web page.
 Out-of-band: data is retrieved using a different channel (e.g., an
email with the results of the query is generated and sent to the
tester).
 Inferential: there is no actual transfer of data, but the tester is
able to reconstruct the information by sending particular requests
and observing the resulting behavior of the DB Server.

19. Type of tests that can be conducted
The tester has to:
make a list of all input fields whose values could be used in crafting a
SQL query, including the hidden fields of POST requests and then test
them separately
 try to interfere with the query and to generate an error. He can add a
single quote (‘) , (;), comments (--) or SQL keywords like ‘AND’ or ‘OR’.
Example of error message that gives to the attacker very useful information:
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113

20. Type of tests that can be conducted
Standard SQL Injection
Union Query SQL Injection
Blind SQL Injection
Store Procedure Injection

21. SQL Injection – Illustrated Get Accounts
Firewall
Hardened OS
Web Server
App Server
Firewall
Databases
LegacySystems
WebServices
Directories
HumanResrcs
Billing
Custom Code
APPLICATION
ATTACK
NetworkLayerApplicationLayer
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
HTTP
request
SQL
query
DB Table


HTTP
response


"SELECT * FROM
accounts WHERE
acct=‘’ OR
1=1--’"
1. Application presents a form to
the attacker
2. Attacker sends an attack in
the form data
3. Application forwards attack to
the database in a SQL query
Account Summary
Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
4. Database runs query
containing attack and sends
encrypted results back to
application
5. Application decrypts data as
normal and sends results to the
user
Account:
SKU:
Account:
SKU:

22. SQL Injection – Illustrated Login Form
SELECT * FROM `Login` WHERE `User`=‘John’ AND
`Pass`=‘John@123’
Login Database Table
John
********John@123
John
User Pass
John John@123

23. SQL Injection – Illustrated get access
SELECT * FROM `Login` WHERE `User`=‘’ OR ‘a’=‘a’
AND `Pass`=‘’ OR ‘a’=‘a’
Always TRUE!!!
’ OR ‘a’=‘a
*********’ OR ‘a’=‘a
’ OR ‘a’=‘a

24. SQL Injection – Illustrated drop the table
SELECT * FROM `Login` WHERE `User`=‘’ ’; DROP TABLE `login`; -- ’
AND `Pass`=‘’
If database is not Readonly!
’; DROP TABLE `login`; --
’; DROP TABLE `login`; --

25. Tools
WebScarab
ZAP
SqlDumper
SQLix
SQLninja
SQLinjector

26. Prevention of SQL Injection
•Applications have to:
validate and to sanitize all user input
never use dynamic SQL
execute using an account with few privileges
hash or encrypt their secrets
present error messages that reveal little if no
useful information to the hacker

27. References
• https://www.owasp.org/index.php/SQL_Injection
• http://www.websec.ca/kb/sql_injection
• http://www.securesolutions.no/why-its-easy-being-a-hacker
/
• http://
pentestmonkey.net/cheat-sheet/sql-injection/oracle-sql-injection-cheat-sheet
• http://www.integrigy.com/files/Integrigy
_Oracle_SQL_Injection_Attacks.pdf
• http://www.owasp.org/index.php/SQL_
Injection_Prevention_Cheat_Sheet
• http://unixwiz.net/techtips/sql-
injection.html

28. End of part one

29. A2.Cross-Site Scripting (XSS)

30. Cross-Site Scripting Illustrated
Application with
stored XSS
vulnerability
3
2
Attacker sets the trap – update my profile
Attacker enters a
malicious script into a
web page that stores
the data on the server
1
Victim views page – sees attacker profile
Script silently sends attacker Victim’s session cookie
Script runs inside
victim’s browser with
full access to the DOM
and cookies
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions

31. Simple XSS Attack
http://myserver.com/test.jsp?name=Stefan
http://myserver.com/welcome.jsp?name=<script>alert("Attacked")</script>
<HTML>
<Body>
Welcome Stefan
</Body>
</HTML>
<HTML>
<Body>
Welcome
<script>alert("Attacked")</script>
</Body>
</HTML>

32. XSS-Attack: Another example
Post Forum Message:
Subject: GET Money for FREE !!!
Body:
<script> attack code </script>
1. Attacker sends malicious code
2. Server stores message
Did you know this?
.....
3. User requests message
4. Message is delivered by server
5. Browser executes script in message
GET Money for FREE !!!
<script> attack code </script>
Get /forum.jsp?fid=122&mid=2241
Attacker
Client
Web Server
GET Money for FREE !!!
<script> attack code </script>
!!! attack code !!!
Re: Error message on startup
.....
I found a solution!
.....
Can anybody help?
.....
Error message on startup
.....

33. XSS Attacks
• Sun Microsystems's Java
• Client-side Script
• JavaScript
• Action Script
• VB Script
• Microsoft’s Active X
• Adobe’s Flash
• HTML or XHTML
• RSS and Atom feeds
Programming Languages Used
in XSS Attacks
XSS Attacks Used For:
• Hijacking Accounts
• False Advertising & inserting
hostile content
• Cookie theft/poisoning &
defacing websites
• Changing of users settings
• Conducting phishing attacks

34. Prevention of XSS Attack
• Input Validation
 Check if the input is what you expect
 Do not try to check for "bad input"
 Black list testing is no solution
 Black lists are never complete!
 White list testing is better
 Only what you expect will pass
 Regular expressions
• HTML Encoding
 HTML encoding of all input when put into output pages
• Cookie Options mitigate the impact
 "httpOnly" Cookies
 "secure" Cookies. Cookies are only sent over SSL

35. References
• http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention
Cheat Sheet
• http://ha.ckers.org/xss.html

36. A3.Broken Authentication and Session Management

37. Broken Authentication Illustrated
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
1 User sends credentials
2Site uses URL rewriting
(i.e., put session in URL)
3 User clicks on a link to
http://www.hacker.com in a forum
www.boi.com?JSESSIONID=9FA1DB9EA...
4
Hacker checks referer logs on
www.hacker.com
and finds user’s JSESSIONID
5
Hacker uses JSESSIONID
and takes over victim’s
account

38. Avoiding Broken Authentication and Session
Management
• Verify your architecture
 Authentication should be simple, centralized, and standardized
 Use the standard session id provided by your container
 Be sure SSL protects both credentials and session id at all times
• Verify the implementation
 Forget automated analysis approaches
 Check your SSL certificate
 Examine all the authentication-related functions
 Verify that logoff actually destroys the session
• Follow the guidance from
 http://www.owasp.org/index.php/Authentication_Cheat_Sheet

39. A4.Insecure Direct Object References

40. Insecure Direct Object References Illustrated
• Attacker notices his
acct parameter is
6065 ?acct=6065
• He modifies it to a
nearby number
?acct=6066
• Attacker views the
victim’s account
information
https://www.onlinebank.com/user?
acct=6065
https://www.onlinebank.com/user?
acct=6066

41. Avoiding Insecure Direct Object References
• Eliminate the direct object reference
 Replace them with a temporary mapping value (e.g. 1, 2, 3)
 ESAPI provides support for numeric & random mappings
• IntegerAccessReferenceMap & RandomAccessReferenceMap
• Validate the direct object reference
 Verify the parameter value is properly formatted
 Verify the user is allowed to access the target object
• Query constraints work great!
• Verify the requested mode of access is allowed to the target object (e.g.,
read, write, delete)
http://app?file=1
Report123.xls
http://app?id=7d3J93
Acct:9182374http://app?id=9182374
http://app?file=Report123.xls

42. A5.Cross Site Request Forgery (CSRF)

43. Cross Site Request Forgery (CSRF)
• Occurs when an authenticated user unknowingly initiates a request
• The request is handled as if it were intentional
Usually happens without the user being aware!
• CSRF attacks are difficult to track
Commands are executed in the context of the victim
The request comes from the users IP address so it is difficult to hunt down the
hacker
• The hacker is essentially given all of the user’s privileges

44. CSRF Vulnerability Pattern
• The Problem
 Web browsers automatically include most credentials with each request
 Even for requests caused by a form, script, or image on another site
• All sites relying solely on automatic credentials are vulnerable!
 (almost all sites are this way)
• Automatically Provided Credentials
 Session cookie
 Basic authentication header
 IP address
 Client side SSL certificates
 Windows domain authentication

45. Prevention of CSRF
• Add a secondary authentication mechanism (e.g., as an impossible to
guess token)
• Require a confirmation page before executing potentially dangerous
actions
• Eliminate XSS vulnerabilities
• Use POST as your form action and only accept POST requests on
the server for sensitive data !
• Incoming CSRF requests will fail since the parameter is in the URL
and not the post body
• You can protect yourself with RequestPolicy (Firefox extension)
References:
– www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

46. A6.Security Misconfiguration

47. Hardened OS
Web Server
App Server
Framework
Security Misconfiguration Illustrated
App Configuration
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
Test Servers
QA Servers
Source Control
Development
Database
Insider

48. Security Misconfiguration. Attack scenarios
• Scenario #1: Your application relies on a powerful framework
like Struts, Spring or MVC. XSS flaws are found in these
framework components you rely on. An update is released to
fix these flaws but you don’t update your libraries. Until you do,
attackers can easily find and exploit these flaw in your app.
• Scenario #2: The app server admin console is automatically
installed and not removed. Default accounts aren’t changed.
Attacker discovers the standard admin pages are on your
server, logs in with default passwords, and takes over.
• Scenario #3: App server configuration allows stack traces to
be returned to users, potentially exposing underlying flaws.
Attackers love the extra information error messages provide.

49. Prevention Security Misconfiguration
• Verify your system’s configuration management
 Secure configuration “hardening” guideline
 Automation is REALLY USEFUL here
 Must cover entire platform and application
 Keep up with patches for ALL components
 This includes software libraries, not just OS and Server applications
 Analyze security effects of changes
• Can you “dump” the application configuration
 Build reporting into your process
 If you can’t verify it, it isn’t secure
• Verify the implementation
 Scanning finds generic configuration and missing patch problems

50. A7.Failure to Restrict URL Access

51. Failure to Restrict URL Access Illustrated
• Attacker notices the
URL indicates his
role
/user/getAccounts
• He modifies it to
another directory
(role)
/admin/getAccounts,
or
/manager/getAccoun
ts
• Attacker views more
accounts than just
their own
https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/admin/getAccounts

52. Avoiding URL Access Control
Flaws
• For each URL, a site needs to do 3 things
 Restrict access to authenticated users (if not public)
 Enforce any user or role based permissions (if private)
 Completely disallow requests to unauthorized page types (e.g., config files,
log files, source files, etc.)
• Verify your architecture
 Use a simple, positive model at every layer
 Be sure you actually have a mechanism at every layer
• Verify the implementation
 Verify that each URL in your application is protected by either
 Verify the server configuration disallows requests to unauthorized file types
 Use WebScarab or your browser to forge unauthorized requests

53. A8.Insecure Cryptographic Storage

54. Insecure Cryptographic Storage Illustrated
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
1
Victim enters credit
card number in form
2Error handler logs CC
details because
merchant gateway is
unavailable
4 Malicious insider
steals 4 million
credit card
numbers
Log files
3
Logs are accessible to
all members of IT staff
for debugging purposes

55. Insecure Cryptographic Storage Prevention
• Verify your architecture
 Identify all sensitive data
 Identify all the places that data is stored
 Ensure threat model accounts for possible attacks
 Use encryption to counter the threats, don’t just ‘encrypt’ the data
• Protect with appropriate mechanisms
 File encryption, database encryption, data element encryption
• Use the mechanisms correctly
 Use standard strong algorithms
 Generate, distribute, and protect keys properly
 Be prepared for key change
• Verify the implementation
 A standard strong algorithm is used, and it’s the proper algorithm for this situation
 All keys, certificates, and passwords are properly stored and protected
 Safe key distribution and an effective plan for key change are in place
 Analyze encryption code for common flaws

56. A9. Insufficient Transport Layer Protection

57. Insufficient Transport Layer Protection Illustrated
Custom Code
Employees
Business Partners
External Victim
Backend Systems
External Attacker
1
External
attacker steals
credentials and
data off
network
2
Internal attacker
steals credentials
and data from
internal network
Internal Attacker

58. Avoiding Insufficient Transport Layer Protection
• Protect with appropriate mechanisms
 Use TLS on all connections with sensitive data
 Individually encrypt messages before transmission
 E.g., XML-Encryption
 Sign messages before transmission
 E.g., XML-Signature
• Use the mechanisms correctly
 Use standard strong algorithms (disable old SSL algorithms)
 Manage keys/certificates properly
 Verify SSL certificates before using them
 Use proven mechanisms when sufficient
 E.g., SSL vs. XML-Encryption
References:
• http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

59. A10.Unvalidated Redirects and Forwards

60. Unvalidated Redirect Illustrated
3
2
Attacker sends attack to victim via email or
webpage
From: Internal Revenue Service
Subject: Your Unclaimed Tax
Refund
Our records show you have an
unclaimed federal tax refund.
Please click here to initiate your
claim.
1
Request sent to
vulnerable site, including
attacker’s destination site
as parameter. Redirect
sends victim to attacker
site
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
4
Victim clicks link containing unvalidated
parameter
Evil Site
http://www.irs.gov/taxrefund/claim.jsp?
year=2006& … &dest=www.evilsite.com

61. Unvalidated Forward Illustrated
2
Attacker sends attack to vulnerable page they have
access to1
Application authorizes
request, which
continues to
vulnerable page
Request sent to
vulnerable page which
user does have access
to. Redirect sends user
directly to private
page, bypassing
access control.
3 Forwarding page fails to validate
parameter, sending attacker to
unauthorized page, bypassing
access controlpublic void doPost( HttpServletRequest request,
HttpServletResponse response) {
try {
String target = request.getParameter( "dest" ) );
...
request.getRequestDispatcher( target ).forward(req
uest, response);
}
catch ( ...
Filter
public void
sensitiveMethod( HttpServletRequest
request, HttpServletResponse
response) {
try {
// Do sensitive stuff here.
...
}
catch ( ...

62. Unvalidated Redirects and Forwards Prevention
 Avoid using redirects and forwards as much as you can
 If used, don’t involve user parameters in defining the target
URL
 Validate each parameter to ensure its valid and authorized for
the current user
 Use server side mapping to translate choice provided to user
with actual target page (preferred)
 Defense in depth: For redirects, validate the target URL after it
is calculated to make sure it goes to an authorized external site

63. OWASP Enterprise Security API
ESAPI Homepage: http://www.owasp.org/index.php/ESAPI

64. It all ends here…
Security Testing is
performed.
Security considerations are
introduced
in development process
&
Unless…

65. Q&A

66. Thank you!
Stefana Botezatu