What are the major attacks against the web applications? In order to find this we have to review the available materials on the internet and different journals.
3.2 Review of web / journals
Study the following sites:
â€¢ Microsoft Corporation (www.microsoft.com)
â€¢ The Open Web Application Security Project (www.owasp.com)
Microsoft Corporation in its paper  has offered five instructions which are given bellow:
"Introduction to Threats and Countermeasures", discovers and illustrates the different threats facing the server, network layers and application layers.
"Designing Secure Web Applications", provides the direction necessary to develop secure Web applications.
"Building Secure Web applications", allows a programmer to apply the secure design practices establish in Part II to build secure implementations.
"Securing Your Network, Host and Application", illustrates how security configuration settings will be functional to secure these consistent levels.
"Assessing Your Security", supply the tools essential to estimate the success of security efforts
The Open Web Application Security Project  was published Top Ten application security risk for secure web application development. According two web journals we picked out eight top threats for this analysis in this project.
3.3 Threat listing
Here we explain the definition of the attack, how the attack occurs and what the countermeasure is for it.
3.3.1 Invalidated input
How the application filters, cleans or rejects input before additional processing are referred by Input validation. Input from HTTP requests is used by Web applications to decide how to take action. Attackers can interfere by using their HTTP request, database query, web header or hidden fields of the web application to try to destroy the security mechanisms. Forced Browsing, Command Insertion, Cross Site Scripting, Buffer Overflows, Format String Attacks, SQL Injection, Cookie Poisoning, and Hidden Field Manipulation are the frequent names for common input tampering.
Some web sites try to defend themselves by filtering the harmful input. The main problem is that different developer use different ways to encode information. These encoding systems are unlike encryption, as they are insignificant to decode. Moreover, sometimes the programmers often forget to decode all parameters to their normal form before using them. Parameters should be converted to the normal form before they are authenticated, or else, harmful input can be shrouded and it can slip past security filters. The procedure of normalize this encoding is named "canonicalization". 
How the attack occurs
Only a client-side technique is used to validate input by an amazing number of web applications. Client side validation mechanisms are easily avoidable and leave the web application without any defense against harmful parameters. Attackers can create their
HTTP requests using different tools to make it as simple as telnet. Attention to anything is not necessary to pay which is meant by developer to happen on the client side. It is to be noted that client side checking is a good idea for performance and usability, but it does not have any security benefit. Server side tests are needed to fight against parameter manipulation attacks. And if this is happened, client side checking will be and reduce the number of illegal traffic to the host. The impact of using illegal input should not be taken too lightly. If the programmers would simply check input before using it, a huge number of attacks would become impossible. Web application needs a strong, key mechanism for validating all input from any sources; otherwise the problems based on corrupt input are likely to live.
The way to prevent attacks is Countermeasures derived from invalidated input. Such as:
â€¢ The primary procession of defense is performance of thorough input validation. A bug may be present in the function that allows expected input to arrive at the beyond the bounds of a contained; however, unexpected input will be the chief cause of this susceptibility. Input must be controlled by validating it for data type, data size, and data boundaries.
â€¢ Use of unmanaged code must be restricted by the Application. Before ensuring that input is properly validated, unmanaged APIs must thoroughly be scrutinized.
â€¢ Scrutiny of the managed scripts that identifies the unmanaged API to make sure that only correct value can be accepted as parameters to the unmanaged API.
â€¢By using HTML Encode and URL Encode methods we can encode any output that contains as user input. This alters the executable script into risk-free HTML scripts.
â€¢ By using parameterized stored procedures for accessing database we can ensure that input data are not considered as executable statements.
3.3.2 Broken Access Control
Granting access to the property and function of the web application to some users is called Access Control. Restrictions on what legitimate users are permitted to do are not correctly enforced. Attackers can take advantage of these imperfections to hack other users' accounts, view confidential files, or use illegal operations.
How the attack occurs
Major attacks that use authorization vulnerabilities are briefly describe here:
Elevation of privilege
When we design an authorization model, we have to conscious that an attacker is always trying to get privileges of a potent user for example a user of local administrators group or system group and thus the attacker can get full control over the server and application.
Disclosure of confidential data
If an unauthorized user can get any confidential data, the disclosure of secret data can occur. Confidential data contains solution related data such as credit card numbers, employee ID, PIN number and so on collectively with solution configuration data such as service account identification and database connection string. To check the leak of secret data it must be protected in constant stores such as databases and configuration files. Only valid and certified users should be able to access the data that is definite to them. And any kind of illegal access to the system level configuration data should be restricted by the administrators.
Data tampering means the illegal change of data.
Luring attack occurs when a user which has a few privileges can get another user with more privileges and start a process on its behalf.
The most significant task is to think about the application's access control requirements and put it in a web application security rule. The access control matrix is highly recommended to define the access control rules. What types of users can access the solution, and what methods and resources each of these types of users can get should be specified by the policy. Access control system should be broadly tested to make sure that there is no way to avoid it. Some particular access control issues are describing here:
â€¢ Insecure Id's - most web sites use id number, key word or password to identify user group with their privileges, contents, or functions. If attackers can presume these id's, and the security system could not identify its legalization as a current user, the attacker can use the access control scheme easily.
â€¢ Forced Browsing Past Access Control Checks - many web sites taking users to pass through some checks before final approval to access a certain URLs that are generally important part of the site. These checks should not be avoidable by a user.
â€¢ Path Traversal - provides related path address as part of a demand for information.
â€¢ File Permissions - Only files that are particularly planned to be displayed to web users should be distinct as readable using the OS's permissions method, most directories should not be readable, and very few files should be marked as executable.
â€¢ Client Side Caching - Various mechanisms like HTTP headers and Meta tags should be used by developers to make sure that user's browsers cannot cache sensitive information.
3.3.3 Broken Authentication
Account identification and session tokens are not appropriately protected. Authentication limitations can be defeated and other users' identities can be guessed by the attackers compromising id, PIN, session cookies, or other tokens. Authentication mechanisms should be chosen and implemented properly otherwise the authentication mechanism will be in risk and attackers can take advantage of to get access to the system.
How the attack occurs
Major attacks that use authorization vulnerabilities are briefly describe here:
Traffic is captured and user names, passwords are obtained of a host on the same network by the attacker even only equipped with elementary network monitoring when authentication credentials are passed in plaintext from client to server.
Brute force attacks
Brute force attacks are an automated process of trial and error used to guess a person's user id, user password, PIN, bank account number, credit-card number or cryptographic key. Brute force attacks based on computational power to split hashed passwords or other secrets secured with hashing and encryption. The usage of weak passwords or cryptographic keys is easily permitted by many systems. Users frequently select passwords which very easy to guess and perhaps found in a dictionary. In this circumstance an attacker searching for the valid password would go through the dictionary word by word, generating thousands or potentially millions of incorrect guesses. Once a guessed password allows access to the system, the brute force attack has been successful and the attacker is able to enter the account. For guessing encryption keys the same experimental and error technique is applicable too. By testing all possible keys an attacker can easily guess a correct key especially when a web site uses a weak or
small key size. A single username against many passwords is used in a normal brute force attack whereas many usernames against one password are used in a reverse brute force attack. In systems with millions of user accounts, the probability of multiple users having the same password dramatically increases. It takes hours, weeks or years even to complete brute force techniques because it is extremely popular and often successful.
Dictionary attack is a universal threat to all passwords. An attacker obtaining some responsive password-derived data, such as a hashed-password, performs a succession of computations using every feasible guess for the password. The dictionary attack finds passwords in a particular list just like an English dictionary do.
Cookie replay attacks
Amid this nature of attack, the invader detains the user's authentication cookie by means of supervising software and repeats it to the purpose to expand a way in under a fake distinctiveness.
If the application executes its own accumulation including user account names and passwords, evaluates its security to the official document supplies made available by the platform, for an instance, a Microsoft Active Directory service or Security Accounts Manager user store. Browser history and browser cache also lay up user login information for the potential utilization. If the terminal is exited by any other person than the user who logged on, and the same page is stricken, the accumulated login will be accessible.
Appropriate utilization of routine verification methods should considerably lessen the probability of a problem. Crucial and scripting the site's policy with deference to firmly supervising user certificate is a good primary step.
A number of other countermeasures comprise:
â€¢ Password strength - passwords should have boundaries that necessitate a least size and intricacy for the password.
â€¢ Password use - Users should be limited to a distinct number of login efforts per unit of time and suitable log of unsuccessful attempts should be reserved.
â€¢ Password change controls - a password change method should be employed every time users are permitted to change a password.
â€¢ Password storage - all passwords must be gathered in either hashed or encrypted form to guard them from revelation, in any case of where they are piled up.
â€¢ Protecting credentials in transit - the only effectual method is to encrypt the total login transaction applying somewhat like SSL.
â€¢ Account lists - when we design the systems we should avoid allowing users to get
access to a list of the account names on the site.
â€¢ Trust relationships - site architecture should keep away from enclosed faith between content when prospective. Each content should validate itself to any other module it is interrelating with unless there is a powerfully constructed reason not to.
3.3.4 Session Management
Session management is the system of maintaining track of a user's action through sessions of communication with the computer system. Session security is important to the overall security system of the application.
How the attack occurs
Major session management threats contain:
A session hijacking attack transpires while an attacker makes use of network supervising software to detain the verification token used to symbolize a user's session with a request. The attacker has the same privileges as the valid user has.
Session replay happen when a valid user's session token is interrupted and submitted by illegal user to avoid the verification device. For an instance, if the session token is in basic manuscript in a cookie or URL, an attacker can breathe in it. The attacker then sends an application using the seized session token.
Man in the middle attacks
A man in the middle attack takes place when the attacker interrupts messages sent between the dispatcher and anticipated receiver. The attacker afterward modifies the message and sends it to the inventive receiver. The receiver obtains the message, perceives that it approached from the dispatcher, and proceeds on it. As the receiver flings a message back to the dispatcher, the attacker interrupts it, modifies it, and revisits it. Dispatcher and receiver never are acquainted with that they have been assaulted. Every network appeal connecting client-server communication, plus Web requests, Distributed Component Object Model applies for, and identifies to distant mechanism and Web services, is obliged to man in the middle attacks.
Session management countermeasures comprise:
â€¢ Session ID protection - Preferably, a consumer's inclusive session should be confined via SSL. Proviso this is done, then the session ID cannot be grasped off the network, which is the principal jeopardy of revelation for a session IS. Session IDs must be altered when transferring to SSL, validating, or other major shifting.
â€¢ Browser caching - we should never send session data with GET and in this case we should always use POST.
3.3.5 Cross-site scripting (XSS)
Cross-site scripting (called XSS) problems occur when a hacker uses a web application to send harmful code to a different end user. Generally the code is in the form of an executable script which is used by the attacker for future use. An XSS attack can create special code to run in a user's browser while the browser is connected to the web site. The attack infects the application's users, not the application itself but it uses the application as the medium for the attack. The attacked script code is downloaded by the browser from a trusted website; the browser doesn't know is the code is harmful. As the hacker's code has the right to use to the cookies connected with the trusted website and are downloaded on the user's local computer, a user's authentication cookies are usually the target of attack.
How the attack occurs
XSS attacks can be classified into two categories: stored and reflected
â€¢ Stored attacks: in where the inserted code is permanently stored on the target servers. It may store in a database, posting in forum, suggestion or opinion field etc. The victim then retrieves the harmful script from the application when it requests for any service.
â€¢ Reflected attacks are distributed to victims via another path, such as in email or web link. When a user is clicking on infected link or submitting the special form, the injected code comes to the naive web server, which returns the attack back to the user's browser. The browser then executed the code, because it comes from the real server.
To prevent cross-site scripting, perform the following steps :
First Step : Confirm that ASP.NET request validation is enabled.
Second Step : Verify whether HTML output includes input parameters.
Third Step : Use URL Encode to encode any output that includes user input.
First Step: Confirm That ASP.NET Request Validation Is Enabled
By default, ASP.NET request validation is enabled in Machine.config file. But we need to check that request validation is presently enabled in our server's Machine.config file and that our application also does not make ineffective this setting in its Web.config file. Ensure that validateRequest is set to true as shown in the following code example.
<pages buffer="true" validateRequest="true" />
Second Step: Verify Whether HTML Output Includes Input Parameters
Analyze our application design and our page code to determine whether the output includes any input parameters. These parameters can come from different sources such as the following:
protected void Page_Load(object sender, EventArgs e)
protected void Page_Load(object sender, EventArgs e)
lbl_ProductName.Text = "Product Name:" + Server.HtmlEncode(Request.QueryString["ProductName"]);
Databases and data access methods:
SqlConnection con = new SqlConnection("DataSource=localhost;Database=db_First;Integrated Security=SSPI");
SqlCommand cmd = new SqlCommand("Select * from UserInfo", con);
SqlDataReader iSqlDataReader = cmd.ExecuteReader();
// Check cookie
lbl_UserName.Text = "Welcome to : " + Server.HtmlEncode(Request.Cookies["Username"].Value);
lbl_UserName.Text = "";
In source code analysis, we can perform a simple test by entering a text such as "ABC" in form fields and observe the output. If the browser displays "ABC" or if we see "ABC" when we open the source of the HTML, our application become vulnerable to cross-site scripting.
Third Step: Encode URL Output
If we return URL strings that hold input to the user, we have to use the HttpUtility.UrlEncode method to encode these URL strings. The code example is as bellow:
protected void Command_BTN_Click(object sender, EventArgs e)
3.3.6 Buffer overflows
While a program writing data to a buffer, it crosses the buffer limit and overwrites the contiguous memory of the server. Buffer overflows used by the attacker to destroy the execution system of a web application. It is not so easy to determine Buffer overflow. It can be present in the web server as well as in the application server to interrupt the static and dynamic service of the site or block the application itself. Buffer overflow attack
occurs in broadly used server products and can create huge threats to users of these products. If the web applications exploit libraries, such as a sound library to generate music, they release themselves to prospective buffer overflow attacks. Buffer overflow can also be attack in custom web application code. Buffer overflow defect in custom web applications are difficult to detect because normally very fewer attackers are trying to find and develop such fault in a specific application. If exposed in a custom application, the process to develop the fault is extensively reduced by the information that the source code and error information for the site are generally not available to the attacker.
How the attack occurs
When data written by the attacker in to the memory, it utilizes all allocated size of the buffer and overwrites the adjacent memory address, and thus an error condition occurs which causing the application to crash.
Countermeasures to help prevent buffer overflows include:
â€¢ Confirm input validation. This is the first step of protection against buffer overflows. Web application input must be constrained by validating for data type, data length, input format and data range. Although a virus may exist in the web application that permits unexpected input which will be the primary cause of buffer overflow and illegal operation.
Validation Control Description
Required Field Validation checks that the user doesn't skip any required input field of the application. Compare Validation compares a user's entry against a predefined value. The value may be a property of another control or a database value. Range Validation Checks that a user's input is between specified borders. Regular Expression Validation Checks that the input data matches a pattern set by a regular expression. Custom Validation Checks the user's input using validation logic that programmer sets.
3.3.7 Injection flaws
A SQL injection attack take advantage of the weakness in input validation to run random
Commands in the database. It can occur when the user can access database through the application and input commands to make dynamic SQL statements. The script is mainly programmed in Perl, Ruby or Python, and can be injected into inadequately designed web applications. If a web application is used as an interpreter, the probability of SQL injection become higher.
Most of the web applications utilize the various features of the operating system and also use other software to perform their task. Email sending, voice chat etc are frequently used external program in web application but many other small programs are also used here. When a web application sends data through internet, as a part of an external request, it must be carefully checked. In this case the attacker can inject unusual data, harmful SQL commands, or program modifiers into the data and the web application then transfer these data on to the external programs for execution.
How the attack occurs
The web attacker tries to find an input parameter of a web application which has a connection with the database and trickily push in malicious SQL instructions into the content of the parameter and finally forward the query into the database. Now SQL attacks are not very complicated to attempt and lot of software's are available to find these defects. The consequences of these attacks are mainly destructive. The attacker destroys the database and crash functions of the web application.
Observe what happens when a client enters the following code in the User Login page:
';DROP DATABASE Ecommerce -- [Where Ecommerce is the Database Name]
With the input, the solution executes the following dynamic SQL statement or the following stored procedure.
// Using Sql Statements to Login Page
SqlConnection conn = new SqlConnection ("Data Source=.\\SQLEXPRESS;AttachDbFilename=|DataDirectory|\\Database.mdf;Integrated Security=True; User Instance=True");
string cmd = "SELECT * FROM [Userinfo] where UserName='" + txtUserName.Text + "'";
SqlDataAdapter da = new SqlDataAdapter(cmd, conn);
The programmer's target was that when the code executes, it takes the client's input and generates a SQL like following statement:
SELECT * FROM [Userinfo] where UserName='Rubel'
But, if the code takes the users malicious input then generates the following statement:
SELECT * FROM [Userinfo] where UserName = ''; DROP DATABASE Ecommerce --'
Here, the ' (single quotation mark) character that starts the harmful input ends the present string literal in the SQL statement. It terminates the existing statement only if the following parsed token does not make sense as a persistence of the present string but does make sense as the initiate of a new statement. Thus, the starting single quotation mark character of the harmful input results in the following statement.
SELECT * FROM [Userinfo] where UserName = '';
On the other hand ; (semicolon) character indicates SQL that this is the end of the present statement, which is then go after by the following malicious SQL code.
; DROP DATABASE Ecommerce
To prevent SQL injection includes:
â€¢ When the web application sending a request to the database, input validation should be performed in appropriately.
â€¢ Parameterized stored procedure should be used for database access
â€¢ Input statements are not being treated as executable statements.
â€¢ If the database dose not uses stored procedures, the input parameters must be used when building commands.
â€¢ Limited user should have the privilege to access the database
Here we describe some of them. :
We should confirm input validation to our ASP.NET applications for input data type, data length, data format, and boundaries. We can protect our web application from SQL injection, by constraining the input which is used to access database.
While we use server controls, we should use the ASP.NET validator controls, such as the RegularExpressionValidator and RangeValidator controls to constrain input. On the other hand if we use regular HTML input controls, then we can use the Regex class in our server-side code to constrain input.
By using a RegularExpressionValidator control as given bellow, we can check our Email Address inputs:
<asp:TextBox ID="txtEmailAddress" runat="server"></asp:TextBox>
<asp:RegularExpressionValidator ID="RegularExpressionValidator1" runat="server"
ErrorMessage="Invalid Email " ControlToValidate="txtEmailAddress"
Use Parameters with Stored Procedures
Stored procedures do not automatically stop SQL injection. We have to use parameters with each stored procedure and it is the important thing. If we do not use parameters, our
stored procedures become vulnerable to SQL injection. The following scripts illustrate how to use SqlParameterCollection while calling a stored procedure in our application.
SqlConnection conn = new SqlConnection("Data Source=.\\SQLEXPRESS;AttachDbFilename=|DataDirectory|\\Database.mdf;Integrated Security=True;User Instance=True");
DataSet ds = new DataSet();
SqlDataAdapter da = new SqlDataAdapter("SP_UserInfo", conn);
da.SelectCommand.CommandType = CommandType.StoredProcedure;
da.SelectCommand.Parameters.Add("@UserEmail", SqlDbType.VarChar).Value = txtEmailAddress;
Here, the @UserEmail parameter is used as a literal value and not as executable script. The parameter is also checked for data type and data length and if it does not conform or match, the SqlParameter class throws an exception.
3.3.8 Application denial of service
Denial of Service (DoS) is an attack which can stop all kind of web service and user activity of the website (Web Application Security Consortium 2004). These malicious attack works by executing a method of significant resources. Most of the times this DoS attacks are trying to occupy all the existing system resources of the website. If a user of these critical resources achieved full operation, at that moment the web site will be unreachable. Web application architecture contains three layers: a web server, a database server and an authentication server. All of these supreme components are might be targeted by the DoS at the application layer. But it will be very difficult at the network layer, because it requires a large number of connections. On the other hand at the application layer it will be easier to perform the attacks for DoS.
How the attack arises
A particular user who attacks the site can produce lot of traffic from one end to run many applications. If we use load balancing technique we can make the attack more difficult,
but we can't prevent the attack completely. We can also reduce the session data of the
application and make difficult to open a new session. If the attacker can manage all of the important resources, they can prevent all other legal user of the application. The attacker tries to consume those resources which are using processor, memory, limited bandwidth, disk storage, etc. For example, if a website can allows all users to send traffic may start lot of database queries. And thus the attacker can frequently send huge requests to the server and there will be none database connection pool left to serve valid users.
As there is no perfect solution to protect the DoS attacks, it is very difficult to defending it completely. Generally, resources allocation should be limited to all users and a quota system should be established for the legitimate users so that any user could not send enough loads to the server. At a time only one request of a user can be accepted by the server and this will be maintained by user's season. When a user release a request will be immediately consider for other user.
Authentication system should be developed and unnecessary access to exclusive resources should be disallowed for unauthenticated user. The design of the application should be architected properly so that an attacker will not be able to start any exclusive operations. Request made by unauthenticated users may be stored instead accessing it. Other countermeasures are:
â€¢ Systematically checking all input data at the server
â€¢Exception handling should be use in the application's code
This section has described on the different type of threats to web applications mostly from the following sources:
The Open Web Application Security Project,
Web Application Security Consortium and the System Administration,
Networking and Security Institute.
According to these sources, we have identified eight regular threats. These eight threats have been explained briefly in this chapter.