Session Management, User Authentication, and Web Application Security
Websites and web applications are frequently targeted environments for security attacks since they are the prime places that users are accustomed to accessing and utilizing. Given the constant user access to websites over the public Internet, the largest amount of security liabilities is the result of a by-product of these accesses. The following explores the components of web application management and the most common website vulnerabilities.
We have already discussed a number of these vulnerabilities that occur with website access. Among these are
■ XSS: Cross-site scripting
■ SQLi: Structured query language injection
■ CSRF: Cross-site request forgery
■ SSL: Secure socket layer corruption
■ Session corruption
■ Information leaking
Session Management and User Authentication
Security breaches commonly begin with the theft of valid user authentication credentials. It is important to understand how hackers use these vulnerabilities in session management and user authentication to gain access to data and network systems.
A session is a sequence of requests and responses from one browser to one (or more) websites. Sessions can be long e-mail sessions (e.g., Gmail) or short texting sessions. Session management is the process of keeping track of a user’s activity across sessions of interaction between the user’s browser and the remote web server. Without session management, users would have to continually log back into websites to complete the sequence of work that the users wish to accomplish using a given website. Session management allows the user to be authorized once, after which all subsequent requests are tied back to that first authorized session and the recognition of that user.
Sessions at the browser level are called Hypertext Transfer Protocol (HTTP) sessions, which allow information to be associated with a particular session user. HTTP session management is made possible through the use of HTTP cookies and session IDs.
A HTTP cookie is a small piece of data that is sent from a website and stored in a user’s web browser while the user is browsing that website. Every time the user accesses the website, the browser sends the cookie back to the server to notify the website of the user’s previous activity. Authentication cookies are the most common method used by web servers to determine whether the user is logged in or not and which account they are logged with. Without such a mechanism, the site would not know whether to send a page containing sensitive information or to require the user to reauthenticate themselves by logging in once again. The security of an authentication cookie generally depends on the security of the issuing website and the user’s web browser and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie’s data to be read by a hacker and used for inappropriate purposes.
A session ID or session token is a small piece of data that is used in HTTP communications to identify a session. For example, a buyer who visits a seller’s site wants to collect a number of items in a virtual shopping cart and then finalize the shopping by navigating to the site’s checkout page. This typically involves an ongoing communication whereby several webpages are requested by the client and sent back to them by the server. In such a situation, it is vital to keep track of the current state of the shopper’s cart, and a session ID is one way to achieve that goal.
A session ID is typically granted to a visitor on their first visit to a site. It is different from a user ID in that sessions are typically short-lived (they expire after a preset time of inactivity, which may be minutes or hours) and may become invalid after a certain processing goal has been met (e.g., once the buyer has finalized his order, he cannot use the same session ID to add more items). As session IDs are often used to identify a user that has logged into a website, they can be used by an attacker to hijack the session and obtain undue privileges.
A session ID is usually a long string of randomly generated numbers designed to decrease the probability of a potential attacker obtaining a valid ID by means of a brute-force search. Once generated, the session ID is sent from a server to a client to identify the current interaction session. The client usually stores and sends back the session ID as a HTTP cookie and also may send it as a parameter in GET or POST queries. Figure 12.1 illustrates the sequences of exchange that take place during the session login and ID validation process.
Figure 12.1 The session login and ID validation process.
There are a number of ways to store session IDs over the course of a session exchange. The three most common are
1. Store the session ID as a browser cookie: (Set-Cookie: SessionToken=fduhye63sfdb)
2. Embed the session ID in URL links: (https://site.com/checkout?SessionToken =kh7y3b)
3. Store the session ID in hidden form: (<input type=“hidden” name=“sessionid” value=“kh7y3b”>)
In practice, none of these options is without its problems. Storing session IDs in browser cookies runs the risk that the browser will advertise the cookie with every information request during the session. This becomes an issue in CSRF attacks, which we will discuss later. Embedding session IDs in URL links leaks the ID through the HTTP reference header, allowing other users to obtain the ID from a public site. Hidden form-field storage is the most secure option, but this does not work for long-term sessions such as Gmail. Effective and secure storage of session IDs requires a combination of all of the foregoing options rather than reliance on a single one.
Having discussed some of the components behind browser mechanisms, we will next examine in more detail the three most common forms of web application security vulnerability and the attacks that make use of these vulnerabilities:
1. SQLi
2. CSRF
3. XSS
Figure 12.2 Basic SQL injection attack.
Structured Query Language Injection
We have previously discussed this common attack technique. SQLi uses the commonly employed SQL command sequence, which is submitted by a user or programmer to search for and retrieve information from a remote, relationally structured database system. The infection injects overwritten sequences that change the meaning of a database access and the SQL request for information command. The attacked browser will send a malicious request to the target server. Ineffective input checking on the target server can lead to malicious SQL queries containing the infected overwritten sequences, which have overwritten the user’s normal query instruction sequence to the victim’s SQL database, forwarding sensitive information back to either the infected user or to the attacker’s browser (Figure 12.2).
An SQL Injection Example: The CardSystems Solutions Attack
In June 2005, it was discovered that CardSystems Solutions, a leading credit card processing company, had been the victim of an SQLi attack in which 43 million credit card numbers were stolen. The attack and marketing fallout eventually put that company out of business.
CSRF is an attack that leverages a user’s session on the victim’s website server. A malicious website sends a browser request to a valid website using the credentials of a valid but innocent victim.
Some common CSRF characteristics are
■ They involve sites that rely on a user’s identity.
■ They exploit the site’s trust in that identity.
■ They trick the user’s browser into sending HTTP requests to a malicious site.
■ They involve HTTP requests that illicit side-effects such as financial transactions or data transmissions (Figure 12.3).
Figure 12.3 Basic cross-site request forgery attack.
A CSRF attack secretly forces a user into submitting a malicious browser request to the user’s server. First, the user establishes a session with a trusted site. While still on the trusted session, the user will unwittingly navigate to another site by means of a malicious link. Once selected, that link will assume the user’s session authentication, in most cases by stealing the user’s session cookie to disguise itself as a legitimate request sent by the victim. The attacker can then access the original session to steal data from the trusted site, sending the money to the attacker instead. The attack will comprise the following steps:
1. Building an exploit URL or script
2. Using social engineering to trick User A into executing the action
The social engineering aspect of the attack tricks User A into loading a malicious URL when he or she logged into the bank application. This is commonly done by means of one of the following techniques:
1. Sending an unsolicited e-mail with HTML content
2. Planting an exploit URL or script on pages that are likely to be visited by the victim while they are also doing online banking
The exploit URL can be disguised as an ordinary link, encouraging the victim User A to click on it. Once clicked, the browser will submit the request to bank.com without any visual indication that the transfer has taken place.
Figure 12.4 Basic cross-site scripting attack.
XSS is an attack that injects malicious script into a trusted context in order to steal information from the valid site (Figure 12.4).
An XSS vulnerability is present when an attacker can inject scripting code into pages generated by a web application. There are several common methods for injecting malicious code:
1. Reflected XSS: The attack script is reflected back to the user as part of a page from the victim site.
2. Stored XSS: The attacker stores the malicious code in a resource managed by the web application, such as a database.
3. Others, such as DOM-based XSS attacks, arbitrary HTML, and scripts could be injected on the client causing forced errors.
Example of an XSS Attack on PayPal
In 2006, PayPal’s user data was compromised on a large scale by an XSS social engineering attack. Attackers contacted PayPal users via e-mail and fooled them into accessing a particular URL hosted on the legitimate PayPal website. The attackers’ previously injected code then redirected these PayPal visitors to a page that warned users that their accounts had been compromised. Victims were then redirected to a phishing site and prompted to enter sensitive financial data.
Session Management and User Authentication Conclusion
With increasing regularity, users traverse the Internet for personal tasks such as online banking, online shopping, and online bill paying. However, while companies tout the convenience of using the web for such purposes, the security threats associated with these activities and emanating from their usage continue to mount. Understanding the basic browser mechanisms and how they can be utilized by attackers is vital for preventing vulnerable data loss and network infiltration.
QUESTIONS
1. What are the four primary categories that network security falls under?
2. This acts as the heart of the Internet and is located in the backbone. What is it?
3. What is the role of a packet sniffer?
4. In what two ways can a packet sniffer usually be set up?
5. What are the general threats in Layer 1 and Layer 2 of the seven-layer model?
6. Why do hackers spoof the IP source address?
7. What does a DHCP server contain?
8. Why is it easy to attack DHCP?