This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
As the new era gives birth to new techniques there is simultaneous reflection in getting down those new inventions. The possibilities of attacks in web applications are quite increasing nowadays. Hence security becomes a challenging task to eradicate the attacks in applications. There are certain methods capable of injecting attacks in systems thereby degrading its performance. The prevention mechanisms have to be followed in order to improve a site's security by analysing the kind of attacks that are also more prolific. This builds a necessity to create awareness among the public about the knowledge of variety of attacks and their preventions. This paper proposes a detailed study about the most frequent security risks in web applications which will lead to the deployment of better security which in turn will depict a very good understanding about the risks involved in web applications and how they are discovered by security professionals for their ultimate removal from infecting the target web applications.
Web applications, website security, vulnerability, preventions
The internet usage has increased in recent years which demands high security for web applications. Without security measures and controls, data might be prone to an attack such as alteration of information in order to corrupt or destroy the data or the network itself. A particular class of attacks commonly referred to as code injection and Cross-Site Scripting have become increasingly popular. Unfortunately, the number of applications vulnerable to these attacks is staggering, and the variety of ways attackers is finding to successfully exploit them is on the increase. Analysis of many sites has indicated that not only are the majority of sites vulnerable, but they are vulnerable to many different methods and much of their content is affected.
Based on WHID report , SQL injection faces the top most vulnerability among the other web application attacks. It is exploited around 19% by hackers. Cross-site Scripting and Cross-site request forgery faces almost 8% and 5% respectively. Hence, the hackers are successfully exploiting the application layer vulnerabilities and so the developers need to be well proficient in the knowledge of the security of web application.
SECURITY RISKS IN WEB APPLICATIONS
Hackers have many techniques at their disposal to attack Web applications, and new methods constantly emerge. This paper deals with how Web application attacks occur, identify common and obscure Web application attacks, and how to protect against this. The most frequent attacks in web applications are
Code Injection is the general name for a lot of attacks which depend on inserting code, which is interpreted by the application. Such an attack may be performed by adding string of characters into a cookie or argument values in the URI. This attack makes use of lack of accurate input/output data validation, for example:
amount of expected data
class of allowed characters
for numerical input, its values
The concept of Code Injection is to add malicious code into an application, which then will be executed. The goal of Code Injection and Command Injection measures are similar. The injection technique includes SQL injection, Include file injection, HTML-script injection, LDAP injection and ASP injection.
2.1.1 SQL injection
SQL injection is the most Website vulnerability today. In this technique, by means of an application, the SQL commands are injected into the database engine. It is a flaw in "web application" development, it is not a Database or web server problem. Most programmers are still not aware of this problem. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.
Consider a web page that has username and password as two fields. The code behind the page will generate a SQL query to check the password against the list of user names:
SELECT * from usertable WHERE users=' 'AND
The attacker will submit the query like the following:
SELECT * from usertable WHERE users='k' OR '1'=1' AND pass= 'anything'
This query will compromise all user data from the table, since the OR '1'='1' statement is always said to be true.
Check and filter user input
There should be length limit on input, since majority of the attacks depend on long query strings.
The suspicious keywords like DROP, INSERT, SELECT, UPDATE are not allowed.
User input must not directly be embedded in SQL statements. Instead, parameterized statements must be used or user input must be carefully escaped or filtered.
Consider an example using Java and JDBC
PreparedStatement prep = conn.prepareStatement ("SELECT * FROM USERS WHERE USERNAME=? AND PASSWORD=?");
2.2 Cross-Site Scripting (XSS)
Cross-Site Scripting causes threats in dynamic websites. It occurs when a web application gathers malicious data from an attacker generally in a form of a browser side script to an unsuspecting user. The end user thinks that script is from a trusted party and executes it. The information such as cookies, session tokens and the information which are sensitive are accessed by the vulnerable script. After the data is collected by the web application, output page for the user is created containing the malicious code but appear as a valid web page.
XSS attack falls under two categories
Stored XSS attack
The injected script will be permanently stored in the servers like in a database, in a message forum, visitor log, and comment field, etc. When an unsuspected user requests the user information, malicious script from the server is retrieved.
Reflected XSS attack
The injected script will not be stored in the servers, but instead an error message, search result or in the form of any request will be sent to the server. The unsuspected user retrieves the vulnerable script through an email message or on web servers. The script will be injected in a server by clicking on a malicious link or by submitting a form. In turn, the browser will get executed believing it is from a trusted location.
Consider the application that uses untrusted data in the construction of the following HTML snippet without validation or escaping:
The attacker modifies the 'CC' parameter in their browser to:
This causes the victim's session ID to be sent to the attacker's website, allowing the attacker to hijack the user's current session.
When an application is deployed without proper validation of user input data, XSS flaws occur. By separating data (untrusted) from active browser content XSS prevention can be done.
The next preferred option is "whitelist" input validation. Before the input is accepted, encoded input should be decoded and should validate the length, characters and format on that data. As many applications accept special characters, this validation will not be a complete prevention.
2.3 Broken Authentication and
Authentication and Session management revolves around identifying the user for each of the sessions. Even if the authentication mechanisms are strong, certain flawed credential mechanisms such as password change,
remember password, account update and its related functions undermine it. Web applications have to develop their own sessions to keep track of the requests from each user. If the session tokens are not properly protected, the attacker can obtain an active session and assume to be the valid user. All authentication credentials and session identifiers have to be protected from flaws such as cross-site scripting to prevent the hijack of user and session identity.
Consider an example that web applications have a forgotten password functionality that allow a user to submit their user name to the application and are taken to a page with secret questions or a temporary password reset function. Attackers can exploit this functionality to enumerate valid user name for the application as the username is half the puzzle to carry out the attack.
To prevent this vulnerability, developers should first ensure that all authenticated parts of the applications should be enclosed with SSL. The most difficult task for a developer is to protect the credentials and session identities. In order to have a secure, robust authentication and efficient session management the following techniques have to be followed:
The strength of the password should be good by providing complexity in passwords which may be in the form of combination of alphabets, numeric and alpha-numeric characters.
The password should be used efficiently by restricting to a number of login attempts per unit time. The date/time of the last successful login and failed login attempts to access the account since that time should be informed to the users.
The password change mechanism has to take place for a single time whenever the user needs to change it. Re-authentication should take place when a user forgets the password because it is possible for an attacker to change the email address and can request for that password.
The password should be stored either in a hashed or encrypted form.
The credentials should be sent through secure channel like SSL.
There is the biggest risk of exposure for a session IDs. The sessions should be protected through SSL. The session IDs should never be included in the URL as the browser can cache it. Session IDs should be long, complicated, random numbers that cannot be easily guessed.
It is recommended to use pseudonym (Screen name) for the usernames in the account lists in order to prevent it from hacking.
Authentication and session data should be submitted in a POST method, instead of GET. To prevent the user credentials from being stored, the browser should have to mark no cache flag and AUTOCOMPLETE=OFF flag.
2.4 Insecure Direct Object References
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Using direct object references, an attacker can access other objects without authorization unless an access control check is in place.
Insecure direct object reference vulnerability has two example categories: Open Redirect and Directory Traversal.
Web application has a parameter that allows the website to redirect the user somewhere else. If this parameter is not implemented properly using a white list, attackers can use this in a phishing attack to lure potential victims to a site of their choosing.
If the file that is stored in the local machine is given to the user by a web application, it has to verify what files are being accessed. If such verification is not done, the attacker can take it as an advantage by displaying some other files in the file system.
Instead of direct mapping, indirect references can be used so that details such as file names, URLs and certain key information cannot be guessed by the attackers. In the case of direct references, proper validation should be done to check whether the user is authorised to view what they intend to access. For example in directory traversal example type, what files the user needs to view are alone granted privileges for access.
2.5 Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery allows an authenticated user to execute unwanted actions on a web application through an email/chat. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data. If the user is authenticated to the site he has rights to know about user's session cookie, basic authentication credentials, IP address, Windows domain credentials, etc. In that case, the web site will have no way to distinguish from the legitimate user which may cause an attack. There will not be any kind of intention for the user to do a malicious task but the attacker will make him/her to perform such task.
Consider a scenario in which Bob wishes to transfer $1000 to Alice's account. In this case attack takes place as:
POST http://bank.com/transfer.do HTTP/1.1
But at that John notices this web application and performs the transfer using the URL parameter as follows:
GET http://bank.com/transfer.do?acct=Alice&amount=100 HTTP/1.1
Using the above said change, John gets a chance to
transfer the amount by making Bob as a victim and constructs the URL as
John tricks Bob by submitting the request using the malicious request generated and sends an email as
<a href="http://bank.com/transfer.do?acct=John & amount=100000">Click To View! </a>
When Bob enters the application as an authenticated user and if he clicks the link, the transfer of $100000 is sent to John's account. To make Bob not to know about the transfer, John can hide the transaction details in a zero-byte image form.
<img src="http://bank.com/transfer.do?acct=John&amount=100000" width="1" height="1" border="0">
When this image tag is included in the email, Bob could see a box specifying it is not possible for the browser to deliver the image. Without any visual rendering, the transfer will take place with the browser submitting the request to the bank.
The Websites have certain prevention measures for CSRF as follows:
Log out the sessions and avoid "remember me" features.
Don't display external images and don't click on the links from untrusted emails or those in spam.
When User-specific tokens are used, it will create a complexity for the attacker to decide the right tokens for submissions.
Reduce time-limit for session cookies.
HTTP referrer header is checked to verify whether the request comes from an authorized page.
Avoid GET methods in HTTP usage.
2.6 Insecure Cryptographic Storage
The sensitive information protection has become a key issue in most web applications. Insecure Cryptographic Storage refers to the improper encryption of sensitive information such as database, identities, passwords, etc. Secure encryption methods are not followed. Many sensitive data, such as credit cards and credentials are not properly protected with suitable encryption or hashing which gain access to attacker to perform identity theft, credit card fraud, or other crimes.
Reasons behind insecure cryptographic storage are
Encrypted data stored in clear text.
Use of encryption algorithms like home grown algorithms, insecure use of strong algorithms or the continued use of proven weak algorithms.
Use of weak or unsalted hashes to protect passwords.
Storing keys in unprotected stores.
Use approved public cryptographic algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing.
Weak algorithms such as MD5 / SHA1 should not be used. It is safer to use SHA-256.
Private keys should never be transmitted over insecure channels and the keys should be generated in offline mode.
Ensure that encrypted data stored on disk is not easy to decrypt.
A company processing, storing or transmitting payment card data must be PCI DSS (Payment Card Industry Data Security Standard) compliant.
2.7 Failure to Restrict URL Access
Failing to restrict URL access typically happens when a page doesn't have the correct access control policy in place. The main idea of this kind of attack is try to discover resources which are not published but they can be accessed using "forced browsing". The purpose of this attack is quite similar to Insecure Direct Object Reference so both have the same goal: get unauthorized access to resources
Hidden pages are defined as pages that don't have a link pointing to them, preventing web crawlers, such as Google, from indexing them. Those pages create failure to restrict URL access situation. Attackers typically find these pages through forceful browsing and the access controls on these pages are not restricted for them.
Developers should assume that users will be aware of hidden functionality.
All file types that the application does not serve, should be blocked.
To prevent any attacks, all URLs should be protected by effective control mechanism.
Include library file out of the web root to prevent file accessing.
2.8 Insufficient Transport Layer Protection
Insufficient transport layer protection will lead to the insecure communication as there is a possibility for the channels to be open for attacks such as interception, injection and redirection which will compromise a web application. The attacker may also redirect the communication channels creating an illusion as the website and the user are communicating with the attacker as the other trusted party indirectly. Hence, the transport layer has to be encrypted by appropriate encryption mechanisms. Typically, websites will follow SSL/TLS to carry out encryption at transport layer.
Consider the web page that uses improperly configured SSL. In that case, browser warnings arise and the user may need to accept such warnings in order to continue with that site. If so, the user enters phishing sites and gives up their credentials.
Cookies should be set with secure flag or as HTTP only.
Servers must be configured to accept only strong ciphers and not provide service for weak ciphers.
Websites have to be frequently updated with newer add-ons.
2.9 Unvalidated Redirects and Forwards
The Web applications have to be properly validated as the attackers may redirect the users to malicious sites or make them access authorized pages. This may attempt in installing malware sites and in disclosing some other sensitive information by the users.
The prevention of this risk is important to avoid the phishers in gaining the user's trust.
Avoid redirects and forwards.
The destination parameter should be valid as it may take the user to the attacker's target page and make them disclose the sensitive data.
This paper describes the information as how to exploit the web application by various risks to acquire the details present in them. By describing the popular risks with prevention methods in the web application, the users can be aware of the threats by which web security can be strengthened to create awareness for the public.