Security Testing

Security Testing

Security Testing is a variant of Software Testing which ensures, that system and applications in an organization, are free from any loopholes that may cause a big loss. Some of the security testing methods that inexpensivecoders team is good at are

• SQL Injection
  • Boolean SQL Injection (High) 
  • Blind SQL Injection (High) 
• Directory listing (Medium)
• Internal server error (Medium)
• User credentials sent in clear text (Medium)
• Debugging enabled (Medium)
• Version disclosure (Medium)
• Clickjacking: X-Frame-Options header missing(Medium)
• Cookie without Secure flag set (Low)
• OPTIONS method is enabled (Low)
• Slow response time (Low)
• Broken links (Informational)
• Google Hacking DataBase [GHDB] (Informational)
• Server version disclosure (Informational)
• Password type input with auto-complete enabled (Informational)
• Possible internal IP address disclosure (Informational)
• Web server default welcome page(Informational)
• OS Command Injection
• Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
• Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
• Improper Access Control (Authorization)
• Use of Hard-coded Credentials
• Missing Authentication for Critical Function
• Missing Encryption of Sensitive Data
• Unrestricted Upload of File with Dangerous Type
• Reliance on Untrusted Inputs in a Security Decision
• Execution with Unnecessary Privileges
• Cross-Site Request Forgery (CSRF)
• Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
• Download of Code Without Integrity Check
• Incorrect Authorization
• Inclusion of Functionality from Untrusted Control Sphere
• Incorrect Permission Assignment for Critical Resource
• Internal Path Disclosure
• Cross-site Scripting 
• Command Injection 
• Command Injection (Blind) 
• Local File Inclusion 
• Remote File Inclusion 
• Remote Code Evaluation 
• HTTP Header Injection 
• Open Redirection 
• WebDAV
• Reflected File Download 
• Insecure Reflected Content 
• XML External Entity 
• File Upload 
• Windows Short Filename 
• Cross-site Scripting (DOM based)

SQL Injection

SQL Injection (SQLi) refers to an injection attack wherein an attacker can execute malicious SQL statements (also commonly referred to as a malicious payload) that control a web application's database server (also commonly referred to as a Relational Database Management System – RDBMS).

Identifying Injections

To make an SQL Injection work, the first step, obviously, is to identify it. To do that, the attacker must first establish some sort of indication regarding errors in the system. Although the error messages themselves are not being displayed, the application should still have some capability of separating right (a valid request) from wrong (an invalid request), and the attacker easily learns to identify these indications, find the errors and identify whether they are SQL related or not.

Recognizing Errors

First, we must understand the types of errors that an attacker can face. A Web application can generate errors of two major types.

1. The first type of error is that generated by the Web server, as a result of some exception in the code. If untouched, these exceptions yield the all too familiar ‘500: Internal Server Error’. Normally, injection of bad SQL syntax (unclosed quotes, for instance), should cause the application to return this type of error, although other errors may lead to such an exception.
2. The second type of error is generated by the application code, and usually indicates better programming. The application expects certain invalid cases, and can generate a specific customized error for them. Although normally these types of errors should come as part of a valid (200 OK) response, they may also be replaced with redirects or other means of concealing, much like the ‘Internal Server Error’.

Types of SQL injection

1. In-band SQLi (Classic SQLi)

   In-band SQL Injection is the most common and easy-to-exploit of SQL Injection attacks. In-band SQL Injection occurs when an attacker is able to use the same communication channel to both launch the attack and gather results.

2. Inferential SQLi (Blind SQLi)

   Inferential SQL Injection, unlike in-band SQLi, may take longer for an attacker to exploit, however, it is just as dangerous as any other form of SQL Injection. In an inferential SQLi attack, no data is actually transferred via the web application and the attacker would not be able to see the result of an attack in-band (which is why such attacks are commonly referred to as “blind SQL Injection attacks”).

3. Out-of-band SQLi

   Out-of-band SQL Injection is not very common, mostly because it depends on features being enabled on the database server being used by the web application. Out-of-band SQL Injection occurs when an attacker is unable to use the same channel to launch the attack and gather results.

Depending on the backend database, the database connection settings and the operating system, an attacker can mount one or more of the following type of attacks successfully:

• Reading, updating and deleting arbitrary data or tables from the database
• Executing commands on the underlying operating system

Actions to Take

1. See the remedy for solution.
2. If you are not using a database access layer (DAL), consider using one. This will help you centralize the issue. You can also use ORM (object relational mapping). Most of the ORM systems use only parameterized queries and this can solve the whole SQL injection problem.
3. Locate all of the dynamically generated SQL queries and convert them to parameterized queries. (If you decide to use a DAL/ORM, change all legacy code to use these new libraries.)
4. Use your weblogs and application logs to see if there were any previous but undetected attacks to this resource.

Remedy

A robust method for mitigating the threat of SQL injection-based vulnerabilities is to use parameterized queries (prepared statements). Almost all modern languages provide built-in libraries for this. Wherever possible, do not create dynamic SQL queries or SQL queries with string concatenation.

Example for Blind SQL Injection (High) 

SQL injection is a vulnerability that allows an attacker to alter back-end SQL statements by manipulating the user input. Improper Neutralization of Special Elements used in an SQL Command is generally called as SQL Injection.An SQL injection occurs when web applications accept user input that is directly placed into a SQL statement and doesn't properly filter out dangerous characters. This is one of the most common application layer attacks currently being used on the Internet. Despite the fact that it is relatively easy to protect against, there is a large number of web applications vulnerable. Your script should filter metacharacters from user input. These days, it seems as if software is all about the data: getting it into the database, pulling it from the database, massaging it into information, and sending it elsewhere for fun and profit. If attackers can influence the SQL that you use to communicate with your database, then suddenly all your fun and profit belongs to them. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security. They could modify the queries to steal, corrupt, or otherwise change your underlying data. They'll even steal data one byte at a time if they have to, and they have the patience and know-how to do so.

SQL injection mitigations
We believe that web application developers often simply do not think about "surprise inputs", but security people do (including the bad guys), so there are three broad approaches that can be applied here.
Sanitize the input

It's absolutely vital to sanitize user inputs to insure that they do not contain dangerous codes, whether to the SQL server or to HTML itself. One's first idea is to strip out "bad stuff", such as quotes or semicolons or escapes, but this is a misguided attempt. Though it's easy to point out some dangerous characters, it's harder to point to all of them. The language of the web is full of special characters and strange markup (including alternate ways of representing the same characters), and efforts to authoritatively identify all "bad stuff" are unlikely to be successful. Instead, rather than "remove known bad data", it's better to "remove everything but known good data": this distinction is crucial. Since - in our example - an email address can contain only these characters:

 abcdefghijklmnopqrstuvwxyz
 ABCDEFGHIJKLMNOPQRSTUVWXYZ
 0123456789
 @.-_+

There is really no benefit in allowing characters that could not be valid, and rejecting them early - presumably with an error message - not only helps forestall SQL Injection, but also catches mere
typos early rather than stores them into the database. Be aware that "sanitizing the input" doesn't mean merely "remove the quotes", because even "regular" characters can be troublesome. In an example where an integer ID value is being compared against the user input (say, a numeric PIN):

 SELECT fieldlist
 FROM table
 WHERE id=23 OR 1=1; -- Boom! Always matches!

In practice, however, this approach is highly limited because there are so few fields for which it's possible to outright exclude many of the dangerous characters. For "dates" or "email addresses" or
"integers" it may have merit, but for any kind of real application, one simply cannot avoid the other mitigations.

Escape/Quote safe the input
Even if one might be able to sanitize a phone number or email address, one cannot take this approach with a "name" field lest one wishes to exclude the likes of Bill O'Reilly from one's application: a quote is simply a valid character for this field. One includes an actual single quote in an SQL string by putting two of them together, so this suggests the obvious - but wrong! - technique of preprocessing every string to replicate the single quotes:

 SELECT fieldlist
 FROM customers
 WHERE name = 'Bill O''Reilly'; -- works OK

However, this naive approach can be beaten because most databases support other string escape mechanisms. MySQL, for instance, also permits \' to escape a quote, so after input of \'; DROP TABLE users; -- is "protected" by doubling the quotes, we get:

 SELECT fieldlist
 FROM customers
 WHERE name = '\''; DROP TABLE users; --'; -- Boom!

The expression '\'' is a complete string (containing just one single quote), and the usual SQL shenanigans follow. It doesn't stop with backslashes either: there is Unicode, other encodings, and parsing oddities all hiding in the weeds to trip up the application designer. Getting quotes right is notoriously difficult, which is why many database interface languages provide a function that does it for you. When the same internal code is used for "string quoting" and "string parsing", it's much more likely that the process will be done properly and safely. Some examples are the MySQL function mysql_real_escape_string() and perl DBD method

$dbh->quote($value). These methods must be used.

Use bound parameters (the PREPARE statement) Though quotesafing is a good mechanism, we're still in the area of "considering user input as SQL", and a much better approach exists: bound parameters, which are supported by essentially all database programming interfaces. In this technique, an SQL statement string is created with placeholders - a question mark for each parameter - and it's compiled ("prepared", in SQL parlance) into an internal form. Later, this prepared query is "executed" with a list of parameters:

Example in perl
 $sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;");
 $sth->execute($email);

Thanks to Stefan Wagner, this demonstrates bound parameters in Java:

Insecure version
 Statement s = connection.createStatement();
 ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = "
 + formField); // *boom*

Secure version
PreparedStatement ps = connection.prepareStatement(
 
"SELECT email FROM member WHERE name = ?");
 ps.setString(1, formField);
 ResultSet rs = ps.executeQuery();

Here, $email is the data obtained from the user's form, and it is passed as positional parameter #1
(the first question mark), and at no point do the contents of this variable have anything to do with SQL statement parsing. Quotes, semicolons, backslashes, SQL comment notation - none of this has any impact, because it's "just data". There simply is nothing to subvert, so the application is be largely immune to SQL injection attacks.
There also may be some performance benefits if this prepared query is reused multiple times (it only has to be parsed once), but this is minor compared to the enormous security benefits. This is probably the single most important step one can take to secure a web application.

Limit database permissions and segregate users
In the case at hand, we observed just two interactions that are made not in the context of a logged-in user: "log in" and "send me password". The web application ought to use a database connection with the most limited rights possible: query-only access to the members table, and no access to any other table.

The effect here is that even a "successful" SQL injection attack is going to have much more limited success. Here, we'd not have been able to do the UPDATE request that ultimately granted us access, so we'd have had to resort to other avenues. Once the web application determined that a set of valid credentials had been passed via the login
form, it would then switch that session to a database connection with more rights. It should go almost without saying that sa rights should never be used for any web-based application. Use stored procedures for database access
When the database server supports them, use stored procedures for performing access on the application's behalf, which can eliminate SQL entirely (assuming the stored procedures themselves are written properly).

By encapsulating the rules for a certain action - query, update, delete, etc. - into a single procedure, it can be tested and documented on a standalone basis and business rules enforced (for instance, the "add new order" procedure might reject that order if the customer were over his credit limit).

For simple queries this might be only a minor benefit, but as the operations become more complicated (or are used in more than one place), having a single definition for the operation
means it's going to be more robust and easier to maintain.

Note: it's always possible to write a stored procedure that itself constructs a query dynamically: this provides no protection against SQL Injection - it's only proper binding with prepare/execute or direct SQL statements with bound variables that provide this protection.

Isolate the webserver
Even having taken all these mitigation steps, it's nevertheless still possible to miss something and leave the server open to compromise. One ought to design the network infrastructure to assume that the bad guy will have full administrator access to the machine, and then attempt to limit how that can be leveraged to compromise other things.
For instance, putting the machine in a DMZ with extremely limited pinholes "inside" the network means that even getting complete control of the webserver doesn't automatically grant full access to everything else. This won't stop everything, of course, but it makes it a lot harder.

Configure error reporting
The default error reporting for some frameworks includes developer debugging information, and this cannot be shown to outside users. Imagine how much easier a time it makes for an attacker if the full query is shown, pointing to the syntax error involved. This information is useful to developers, but it should be restricted - if possible - to just internal users

Example for Internal server error (Medium)
This page contains an error/warning message that may disclose sensitive information. The message can also contain the location of the file that produced the unhandled exception. This may be a false positive if the error message is found in documentation pages. Review the source code to fix this issue

Example for Clickjacking: X-Frame-Options header missing (Low)
Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. The server didn't return an X-Frame-Options header which means that this website could be at risk of a clickjacking attack. The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page inside a frame or iframe. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. This can be fixed by Configure your web server to include an X-Frame-Options header. Consult Web references for more information about the possible values for this header.

Example for OPTIONS method is enabled (Low)
HTTP OPTIONS method is enabled on this web server. The OPTIONS method provides a list of the methods that are supported by the web server, it represents a request for information about the communication options available on the request/response chain identified by the Request-URI. It's recommended to disable OPTIONS Method on the web server. 

Example for Web server default welcome page (Informational)
This web server has a default welcome page. If you are not using this web server, it should be disabled because it may pose a security threat. If this server is not used, it is recommended to disable it.

Internal Path disclosure

There is no direct impact, however this information can help an attacker identify other vulnerabilities or help during the exploitation of other identified vulnerabilities. Ensure this is not a false positive. Due to the nature of the issue, Netsparker could not confirm that this file path was actually the real file path of the target web server.
Error messages should be disabled.
Remove this kind of sensitive data from the output.

External References
OWASP - Full Path Disclosure

Classification
HIPAA-164.306(A), 164.308(A)

 

Version disclosure
This information can help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version. An attacker might use the disclosed information to harvest specific security vulnerabilities for the version identified.

Example for Version disclosure (Medium) 

Let us assume the application is developed using ASP.Net and its version is disclosued. What will happen?
The HTTP responses returned by this web application include anheader named X-AspNet-Version. The value of this header is used by Visual Studio to determine which version of ASP.NET is in use. It is not necessary for production sites and should be disabled. Then how should the developer fix this? This can be fixed as below.

Apply the following changes to the web.config file to prevent ASP.NET version disclosure:

< httpRuntime enableVersionHeader="false" /> 

Remedy References

• Error Handling in ASP.NET Pages and Applications
• Remove Unwanted HTTP Response Headers

Classification

• HIPAA-164.306(A), 164.308(A)

Example for Cookie without Secure flag set (Low)
When a cookie is set with the Secure flag, it instructs the browser that the cookie can only be accessed over secure SSL channels. This is an important security protection for session cookies. The developer can fix this by setting the cookie with secure flag.

Example for version disclosure (Informational)
Let us assume that the application is developed using ASP.Net and IIS version is disclosed, The HTTP responses returned by this web application include a header named Server. The value of this header includes the version of Microsoft IIS server. To fix this, Microsoft IIS should be configured to remove unwanted HTTP response headers from the response. 

Example for User credentials are sent in clear text (Medium)
User credentials are transmitted over an unencrypted channel. This information should always be transferred via an encrypted channel (HTTPS) to avoid being intercepted by malicious users. Because user credentials are considered sensitive information, should always be transferred to the server over an encrypted connection (HTTPS).

Example for Debugging Enabled (Low)
Let us assume the application developed using ASP .Net has debugging enabled, ASP.NET debugging is enabled on this application. It is recommended to disable debug mode before deploying a production application. By default, debugging is disabled, and although debugging is frequently enabled to troubleshoot a problem, it is also frequently not disabled again after the problem is resolved.

Example for Password type input with auto-complete enabled (Informational)
When a new name and password is entered in a form and the form is submitted, the browser asks if the password should be saved.Thereafter when the form is displayed, the name and password are filled in automatically or are completed as the name is entered. An attacker with local access could obtain the cleartext password from the browser cache. This can be fixed by disabling the auto-complete feature in the code as

Example for GHDB:

1. Administrative login page (Informational)
2. Possible server upload portal (Informational)

The description for this alert is contributed by the GHDB community, it may contain inappropriate language.
Category : Files containing juicy info
This search can find administrative login pages. Not a vulnerability in and of itself, this query serves as a locator for administrative areas of a site. Further investigation of the surrounding directories
can often reveal interesting information. The Google Hacking Database (GHDB) appears courtesy of the Google Hacking community

Example for Directory listing (Medium)
The web server is configured to display the list of files contained in this directory. This is not recommended because the directory may contain files that are not normally exposed through links
on the web site
You should make sure the directory does not contain sensitive information or you may want to restrict directory listings from the web server configuration.
How to disable directory listings
- The easiest way to disable directory listing is to create an index file. The name of the index file
depends on the web server configuration. On Apache is called index.htm, index.html. On IIS is
named default.asp, default.aspx, default.htm.
- On IIS directory listings are disabled by default.
- For Apache you need to edit the Apache configuration file (usually named httpd.conf) or create an
.htaccess file. In the configuration file you will have the definition of the directory. Something like

Options Indexes FollowSymLinks
...

To disable directory listing for that directory you need to remove the 'Indexes' option

Example for Possible internal IP address disclosure (Informational)
A string matching an internal IPv4 address was found on this page. This may disclose information about the IP addressing scheme of the internal network. This information can be used to conduct further attacks. This alert may be a false positive, manual confirmation is required. This can be fixed by Preventing this information from being displayed to the user.

OS Command Injection
Improper Neutralization of Special Elements used in an OS Command is known as OS Command Injection. This is also called as shell injection. Since the software is often a bridge between an outsider on the network and the internals of the operating system, When another program is invoked on the operating system, untrusted inputs are allowed to be fed into the command string that is generated for executing that program. This opens the door by inviting attackers to cross that bridge into a land of riches by executing their own commands.

Classic Buffer Overflow
Buffer Copy without Checking Size of Input is termed as Classic Buffer Overflow. Buffer overflows are Mother Nature's little reminder of that law of physics that says: if you try to put more stuff into a container than it can hold, you're going to make a mess. The scourge of C applications for decades, buffer overflows have been remarkably resistant to elimination. However, copying an untrusted input without checking the size of that input is the simplest error to make in a time when there are much more interesting mistakes to avoid. That's why this type of buffer overflow is often referred to as "classic." It's decades old, and it's typically one of the first things you learn about in Secure Programming

Cross-site Scripting (CSS)
Improper Neutralization of Input During Web Page Generation is called Cross-site Scripting (CSS). Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications. It's pretty much inevitable when you combine the stateless nature of HTTP, the mixture of data and script in HTML, lots of data passing between web sites, diverse encoding schemes, and feature-rich web browsers. If you're not careful, attackers can inject Javascript or other browser-executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you (because, after all, it *did* come from you). Suddenly, your web site is serving code that you didn't write. The attacker can use a variety of techniques to get the input directly into your server, or use an unwitting victim as the middle man in a technical version of the "why do you keep hitting yourself?" game.

Missing Authentication for Critical Function
In countless action movies, the villain breaks into a high-security building by crawling through heating ducts or pipes, scaling elevator shafts, or hiding under a moving cart. This works because the pathway into the building doesn't have all those nosy security guards asking for identification. Software may expose certain critical functionality with the assumption that nobody would think of trying to do anything but break in through the front door. But attackers know how to case a joint and figure out alternate ways of getting into a system.

Improper Access Control (Authorization)
Suppose you're hosting a house party for a few close friends and their guests. You invite everyone into your living room, but while you're catching up with one of your friends, one of the guests raids your fridge, peeks into your medicine cabinet, and ponders what you've hidden in the nightstand next to your bed. Software faces similar authorization problems that could lead to more dire consequences. If you don't ensure that your software's users are only doing what they're allowed to, then attackers will try to exploit your improper authorization and exercise unauthorized functionality that you only intended for restricted users.

Use of Hard-coded Credentials
Hard-coding a secret password or cryptograpic key into your program is bad manners, even though it makes it extremely convenient - for skilled reverse engineers. While it might shrink your testing and support budgets, it can reduce the security of your customers to dust. If the password is the same across all your software, then every customer becomes vulnerable if (rather, when) your password becomes known. Because it's hard-coded, it's usually a huge pain for sysadmins to fix. And you know how much they love inconvenience at 2 AM when their network's being hacked - about as much as you'll love responding to hordes of angry customers and reams of bad press if your little secret should get out. Most of the CWE Top 25 can be explained away as an honest mistake; for this issue, though, customers won't see it that way. Another way that hard-coded credentials arise is through unencrypted or obfuscated storage in a configuration file, registry key, or other location that is only intended to be accessible to an administrator. While this is much more polite than burying it in a binary program where it can't be modified, it becomes a Bad Idea to expose this file to outsiders
through lax permissions or other means.

Missing Encryption of Sensitive Data
Whenever sensitive data is being stored or transmitted anywhere outside of your control, attackers may be looking for ways to get to it. Thieves could be anywhere - sniffing your packets, reading your databases, and sifting through your file systems. If your software sends sensitive information across a network, such as private data or authentication credentials, that information crosses many different nodes in transit to its final destination. Attackers can sniff this data right off the wire, and it doesn't require a lot of effort. All they need to do is control one node along the path to the final destination, control any node within the same networks of those transit nodes, or plug into an available interface. If your software stores sensitive information on a local file or database, there may be other ways for attackers to get at the file. They may benefit from lax permissions, exploitation of another vulnerability, or physical theft of the disk. You know those massive credit card thefts you keep hearing about? Many of them are due to unencrypted storage.

Unrestricted Upload of File with Dangerous Type
You may think you're allowing uploads of innocent images (rather, images that won't damage your system - the Interweb's not so innocent in some places). But the name of the uploaded file could contain a dangerous extension such as .php instead of .gif, or other information (such as content type) may cause your server to treat the image like a big honkin' program. So, instead of seeing the latest paparazzi shot of your favorite Hollywood celebrity in a compromising position, you'll be the one whose server gets compromised.

Reliance on Untrusted Inputs in a Security Decision
In countries where there is a minimum age for purchasing alcohol, the bartender is typically expected to verify the purchaser's age by checking a driver's license or other legally acceptable proof of age. But if somebody looks old enough to drink, then the bartender may skip checking the license altogether. This is a good thing for underage customers who happen to look older. Driver's licenses may require close scrutiny to identify fake licenses, or to determine if a person is using someone else's license. Software developers often rely on untrusted inputs in the same way, and when these inputs are used to decide whether to grant access to restricted resources, trouble is just around the corner.

Execution with Unnecessary Privileges
Your software may need special privileges to perform certain operations, but wielding those privileges longer than necessary can be extremely risky. When running with extra privileges, your application has access to resources that the application's user can't directly reach. For example, you might intentionally launch a separate program, and that program allows its user to specify a file to open; this feature is frequently present in help utilities or editors. The user can access unauthorized files through the launched program, thanks to those extra privileges. Command execution can happen in a similar fashion. Even if you don't launch other programs, additional vulnerabilities in your software could have more serious consequences than if it were running at a lower privilege level.

Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery usually happens in forms. Cross-site request forgery is like that strange package, except the attacker tricks a user into activating a request that goes to the site. If Cross-Site Request Forgery is found in login form what will happen. In a login CSRF attack, the attacker forges a login request to an honest site using the attacker’s user name and password at that site. If the forgery succeeds, the honest server responds with a Set-Cookie header that instructs the browser to mutate its state by storing a session cookie, logging the user into the honest site as the attacker. This session cookie is used to bind subsequent requests to the user’s session and hence to the attacker’s authentication credentials. The attacker can later log into the site with his legitimate credentials and view private information like activity history that has been saved in the account.

In this particular case CSRF affects the login form in which the impact of this vulnerability is decreased significantly. Unlike normal CSRF vulnerabilities this will only allow an attacker to exploit some complex XSS vulnerabilities otherwise it can't be exploited.

For example;

If there is a page that's different for every user (such as "edit my profile") and vulnerable to XSS (Cross-site Scripting) then normally it cannot be exploited. However if the login form is vulnerable, an attacker can prepare a special profile, force victim to login as that user which will trigger the XSS exploit. Again attacker is still quite limited with this XSS as there is no active session. However the attacker can leverage this XSS in many ways such as showing the same login form again but this time capturing and sending the entered username/password to the attacker.

In this kind of attack, attacker will send a link containing html as simple as the following in which attacker's user name and password is attached.

 

When the victim clicks the link then form will be submitted automatically to the honest site and exploitation is successful, victim will be logged in as the attacker and consequences will depend on the website behavior.

Search History
Many sites allow their users to opt-in to saving their search history and provide an interface for a user to review his or her personal search history. Search queries contain sensitive details about the user’s interests and activities and could be used by the attacker to embarrass the user, to steal the user’s identity, or to spy on the user. Since the victim logs in as the attacker, the victim's search queries are then stored in the attacker’s search history, and the attacker can retrieve the queries by logging into his or her own account.

Shopping
Merchant sites might save the credit card details in user's profile. In login CSRF attack, when user funds a purchase and enrolls the credit card, the credit card details might be added to the attacker's account.

To fix this

Send additional information in each HTTP request that can be used to determine whether the request came from an authorized source. This "validation token" should be hard to guess for attacker who does not already have access to the user's account. If a request is missing a validation token or the token does not match the expected value, the server should reject the request.

If you are posting form in ajax request, custom HTTP headers can be used to prevent CSRF because the browser prevents sites from sending custom HTTP headers to another site but allows sites to send custom HTTP headers to themselves using XMLHttpRequest.

For native XMLHttpRequest (XHR) object in JavaScript;
xhr = new XMLHttpRequest();
xhr.setRequestHeader('custom-header', 'value');
For JQuery, if you want to add a custom header (or set of headers) to
a. individual request

$.ajax({
url: 'foo/bar',
headers: { 'x-my-custom-header': 'some value' }
});
b. every request

$.ajaxSetup({
headers: { 'x-my-custom-header': 'some value' }
});

OR

$.ajaxSetup({
beforeSend: function(xhr) {
xhr.setRequestHeader('x-my-custom-header', 'some value');
}
});

External References

• OWASP Cross-Site Request Forgery (CSRF)
• Robust Defenses for Cross-Site Request Forgery
• Identifying Robust Defenses for Login CSRF

Remedy References

• OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

Classification

HIPAA-164.306(A)

Path Traversal
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). While data is often exchanged using files, sometimes you don't intend to expose every file on your system while doing so. When you use an outsider's input while constructing a filename, the resulting path could point outside of the intended directory. An attacker could combine multiple ".." or similar sequences to cause the operating system to navigate out of the restricted directory, and into the rest of the system.

Download of Code Without Integrity Check
You don't need to be a guru to realize that if you download code and execute it, you're trusting that the source of that code isn't malicious. Maybe you only access a download site that you trust, but attackers can perform all sorts of tricks to modify that code before it reaches you. They can hack the download site, impersonate it with DNS spoofing or cache poisoning, convince the system to redirect to a different site, or even modify the code in transit as it crosses the network. This scenario even applies to cases in which your own product downloads and installs its own updates. When this happens, your software will wind up running code that it doesn't expect, which is bad for you but great for attackers.

Incorrect Authorization
While the lack of authorization is more dangerous (see elsewhere in the Top 25), incorrect authorization can be just as problematic. Developers may attempt to control access to certain resources, but implement it in a way that can be bypassed. For example, once a person has logged in to a web application, the developer may store the permissions in a cookie. By modifying the cookie, the attacker can access other resources. Alternately, the developer might perform authorization by delivering code that gets executed in the web client, but an attacker could use a customized client that removes the check entirely

Inclusion of Functionality from Untrusted Control Sphere
The idea seems simple enough (not to mention cool enough): you can make a lot of smaller parts of a document (or program), then combine them all together into one big document (or program) by "including" or "requiring" those smaller pieces. This is a common enough way to build programs. Combine this with the common tendency to allow attackers to influence the location of some of these pieces - perhaps even from the attacker's own server - then suddenly you're importing somebody else's code. In these Web 2.0 days, maybe it's just "the way the Web works," but not if security is a consideration.

Incorrect Permission Assignment for Critical Resource
It's rude to take something without asking permission first, but impolite users (i.e., attackers) are willing to spend a little time to see what they can get away with. If you have critical programs, data stores, or configuration files with permissions that make your resources readable or writable by the world - well, that's just what they'll become. While this issue might not be considered during implementation or design, sometimes that's where the solution needs to be applied. Leaving it up to a harried sysadmin to notice and make the appropriate changes is far from optimal, and sometimes impossible.

Similar Posts:List of Security Testing Tools, Security Testing,

See Also:Security Testing