Inspecting web applications for bugs, vulnerabilities and threats.

1. Introduction

The purpose of this document is to provide high level information on various web application security risks and what can be done to protect against each one. Knowledge about possible forms of web attacks is essential for web application developers and administrators. However, complete technical details on the vulnerabilities and fixes are beyond the scope of this document.

The security risks covered in this document are:

Injection
Cross Site Scripting
Broken Authentication and Session Management
Insecure Direct Object References
Cross Site Request Forgery
Security Misconfiguration
Insecure Cryptographic Storage
Failure to Restrict URL Access
Insufficient Transport Layer Protection
Un-validated Redirects and Forwards

It is important to note that there are more possible forms of web attacks. The vulnerabilities covered in this document are merely the “Top 10” as defined by the Open Web Application Security Project (OWASP). OWASP is an open community focused on enabling organizations to conceive, develop, acquire, operate and maintain applications that can be trusted. After looking at the top 10 risks, we will look into WebSEAL features and configuration that can be used to help defend against some of the risks.

2. Top 10 Risks

2.1 Injection

2.1.1 Overview

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious command can trick the interpreter into executing unintended commands or accessing unauthorized data.

SQL Injection is one of the first forms of web vulnerabilities but is still popular today. It is one of the most damaging forms of attack because hackers are able to access back-end databases. Databases can be compromised, data can be altered, and/or sensitive data can be pulled out by an attacker without being noticed. Depending on the application’s security measures, the impact of this attack can vary from basic information leak to remote code execution and complete system compromise.

One example of how a SQL injection attack might be executed is through a URL. Hackers know that URL values are often used to search databases for information. For example a URL like this:

http://www.demo.xyz/personrecord.php?userid=100

A hacker can guess that userid=100 is probably going to be used by the application in a sql query to the backend database. So, they can try to inject SQL into the URL with something that might look like this:

http://www.demo.xyz/personrecord.php?userid=100 UNION ALL SELECT USER FROM USER_TABLE;–

Then they wait and see how the application will react. This initial attempt will probably not work. If they did get it right and it works, then they will see the information when the application responds. If it doesn’t work, the application might return with an error message. Depending on how the application was coded, it might come back with an error message that came from the database. Unfortunately, these type of error messages usually helps the attacker in getting the command right. For example, an error message from the database might say something like:

80040e14 [Microsoft][ODBC SQL Server Driver][SQL All queries in an SQL statement containing a UNION operator must have an equal number of expressions in their target lists..

In this case, the hacker now knows that they just need to get the right number of columns in their sql to get a valid response from the application. It’s only a matter of time before the hacker successfully executes the code on the database and compromise the system.

Another form on SQL Injection is known as the Blind SQL Injection. In a blind SQL injection attack, the hacker is not presented with error messages from the database. This is the more common form of sql injection attacks because web developers have learned that showing database error messages in the browser is bad. However, this only makes it more difficult for the hacker to figure out the proper command and compromise the system. It’s still just a matter of time before a determined hacker can execute a successful attack.

2.1.2 Real Life Example

In April 2011, hundreds and possibly millions of websites were hit by a massive sql injection attack.

http://www.pcworld.com/article/223995/millions_of_sites_hit_with_massinjection_cyberattack.html

In July 2011, Anonymous, an internet hacking activist group used a simple SQL injection to successfully gain access to NATO servers from the internet.

http://www.h-online.com/security/news/item/Anonymous-hacks-NATO-servers-1284000.html

2.1.3 Defenses

Injection, at its very root, is a data validation issue. One primary defense that can be used against an injection attack is to use safe APIs which avoids the use of the interpreter entirely or provides a parameterized interface. In terms of SQL injection, always use parameterized queries instead of simply concatenating strings to formulate the SQL query. Another defense that can help, although not a complete defense, is data type validation (i.e., validate that the value supplied by the user is of the correct data type expected by the application).

2.2 Cross Site Scripting (XSS)

2.2.1 Overview

In a cross site scripting attack, the user’s browser is compromised and made to execute malicious code. The success of this attack typically requires the user to execute a malicious URL which may be formed in such a way to appear to be legitimate. When the victim clicks on the URL, the attacker can execute malicious code in the victim’s browser.

Typical areas in an application that could be vulnerable to cross site scripting are:

Search pages that return the searched term in the response page.
Login pages that return an error message for an incorrect login together with the login entered.
Blog type articles that allows users to enter comments that have script tags.

As an example, a hacker might try a XSS attack on a search page by using something like this as the search term:

Customer help <script>alert(document.cookie);</script>

In the example above, the hacker included JavaScript code in the search term. If the application simply takes the search term and displays it back on the response page, the browser will end up executing the javascript. In this case, it merely shows the page cookies in a popup box. But the possibility for more malicious code certainly exists.

Once the hacker has confirmed that a site is vulnerable to XSS, they could package the attack in a URL then send the link to unsuspecting victims and trick them to clicking it. For example:

http://www.demo.xyz/search.aspx?query=Customer%20help<script>alert(document.cookie);</script>

Another possible form of attack is when the application unknowingly allows the user to save the malicious code onto the application database. An example of this is when an application page allows users to enter some text that gets saved into the database (e.g., comments in a blog type page that allows script tags). In this case, the hacker can put in the malicious code as a comment and it will automatically load whenever the page is loaded. This is known as stored XSS and is more severe than regular XSS because the malicious code has been stored in the application. The hacker no longer needs to send any link that might be suspicious to the victim. Simply visiting the page will trigger the attack on unsuspecting users.

2.2.2 Real Life Example

A popular XSS attack is the Samy XSS worm that hit MySpace in November 2005. Samy Kankar, the author of the XSS worm, was able to get over 1 million friends in 24 hours. He was able to do it by storing an XSS exploit into his own profile. Every user that visited his profile page executed the code and added him as a friend. In addition, the XSS worm got injected into their own profiles. When their friends visited their profile page, they unknowingly executed the malicious code as well and got the worm injected into their profile.

http://betanews.com/2005/10/13/cross-site-scripting-worm-hits-myspace/

2.2.3 Defenses

The best defense against XSS vulnerability is to properly escape all untrusted data based on the HTML content that the data will be placed into. “Escaping” is a technique used to ensure that characters are treated as data, not as characters that are relevant to the interpreter’s parser. It lets the interpreter know that the data is not intended to be executed. Another option that can help prevent an XSS attack is to use a positive or whitelist input validation. However, this is not a complete defense as many applications need to accept special characters.

2.3 Broken Authentication and Session Management

2.3.1 Overview

HTTP is a stateless protocol. Web applications use session IDs to track state. In a typical web application, the user will be required to login with a username and password. When a user logs in to a server, a session id is created. The session id might look like this:

sessionID=1ADI133DWP0923KXPOK135

At that point, the application identifies the user through the session id. The user will be allowed to navigate through pages in the application without the need to re-login.

Session Hijacking typically occurs in public wi-fi hotspots such as those in airports, hotels, or coffee shops. Hackers typically would sit around public wi-fi hotspots and use network sniffers to see network traffic that flows through the wi-fi network. They might see network traffic that would look like this:

POST/client.jsp?account=1003 HTTP/1.0

Host: www.demo.xyz

Cookie: sessionID=1ADI133DWP0923KXPOK135

A hacker can now take the traffic they capture and inject it into their browser using a proxy tool. At this point they can impersonate the victim as the application will simply take the sessionID and think that the hacker is the original user that logged in.

2.3.2 Real Life Example

In October 2010, a new Firefox addin named Firesheep allowed users to view and hijack others’ sessions on popular sites like Facebook, Twitter, Amazon, etc., and impersonate the victim.

http://securitywatch.pcmag.com/apple/283724-with-firesheep-all-your-http-sessions-belong-to-us

2.3.3 Defenses

A couple of best practices can work together in defending against this vulnerability:

Use of SSL.
Short session timeouts.

By having the application accept only SSL connections, all communications between the application and browser will be encrypted. A hacker might be able to use a network sniffer tool to see the traffic, but they will not be able to understand it as it will be encrypted.

Having short session timeouts can help in reducing the impact of session IDs falling into the wrong hands. For example, having a session timeout setting of 2 hours means that if a hacker is able to get the session id, it will only valid for a maximum of 2 hours.

2.4 Insecure Direct Object References

2.4.1 Overview

Insecure direct object references, or parameter manipulation is a vulnerability that is extremely simple to execute but can cause big problems because users often gain access to functionality that they are not supposed to have. It is caused by insufficient validation of user input.

Use of URL parameters is common in web applications. A typical URL parameter might look like this:

http://www.demo.xyz/viewAccountDetails.aspx?profile=12353&type=checking

The problem is that the values are very visible and easy to modify. An attack begins when the hacker manipulates the parameter values and sees how the application would respond. In the example above, the hacker might try changing the profile parameter to a different value and see how the application handles it. If the application does not have good validation techniques, the hacker might just get to see the details of someone else’s checking account.

2.4.2 Real Life Example

In December 2007, a parameter manipulation attack was inadvertently executed in Passport Canada’s website by a common citizen. The individual was able to see other people’s passport applications by simply changing a number value in the URL.

http://www.cbc.ca/news/story/2007/12/04/passport-security.html

2.4.3 Defenses

The best defense for a parameter manipulation attack is to treat every input from the client as potentially malicious. Data coming from a client should always be validated if there is a possibility that it has been altered. An application can have a central security checkpoint to validate all input coming from the browser and defend multiple types of attacks. For example, a typical payment URL from a bank might look like this:

http://www.demo.xyz/payment.aspx?bal=100.00&m=VISA

A hacker might try different types of attacks:

http://www.demo.xyz/payment.aspx?bal=’<script>alert(document.cookie);</script>’&m=VISA
http://www.demo.xyz/payment.aspx?bal=-100.00&m=VISA
http://www.demo.xyz/payment.aspx?bal=100.00&m=VISA union select user from table;–

The first one is a cross site scripting attack. The second one is parameter manipulation. In this case, the payment amount was altered to a negative number. Perhaps the hacker is trying to see if the application would actually credit his VISA card with $100.00. The third attack is a sql injection attack. Web applications should consider all possibilities when validating user input as there are obviously many different forms of attack. The other effective defense against parameter manipulation is to not use URL parameters at all and use session variables instead. By using session variables, nothing is visible to the user and there would be nothing for the hacker to tamper with.

2.5 Cross Site Request Forgery

2.5.1 Overview

Cross Site Request Forgery (XSRF) takes advantage of the key ways that the web works. When users are logged in to a site, a hacker can force the user to submit another request without the user’s knowledge. Users then perform actions in their authenticated sessions without them knowing, hence “forgery”.

An example of when an XSRF vulnerability is exploited is when a user is logged into an online banking site. Once the user logs in, they start an authenticated session with the application. Until the user terminates their session or the session times out, any request that comes will be treated by the application as a valid and authenticated request.

A hacker who exploits XSRF vulnerabilities would place common bank action URLS (e.g., payment, transfer, etc.) onto a malicious site. When the malicious site is ready, the hacker will need to trick a user who has an active authenticated session with the bank, to click on a link in the malicious site. Typically the malicious page will have multiple bank action URLS embedded as image source links in an HTML image tag and it will show up as an invalid image on the browser page. Because of this, it will not be obvious to the user that they are actually executing transactions on their bank site because as far as they know, they are navigating a different site (not their bank). But because they have a current active session with the bank, the commands on the malicious page would execute using their authenticated session without them ever knowing. An example malicious action in an HTML image tag might look like this:

2.5.2 Real Life Example

In August 2009, Facebook was hit by cross site request forgery attack. Hackers were able to trick Facebook users to load an infected page. The infected page had an HTML image tag with the malicious command. The user’s ID, profile picture and list of friends were exposed to the attacker.

http://www.internetnews.com/security/article.php/3835596/Facebook+Hit+by+CrossSite+Request+Forgery+Attack.htm

2.5.3 Defenses

XSRF can be difficult to defend against but there are a few best practices that could help:

Decrease session timeouts.
XSRF tokens.
Re-authentication.

In order for XSRF to work, the user must have an active authenticated session with the target site. Reducing the time that a session remains active reduces the window where a hacker could launch an XSRF attack. XSRF tokens can be employed by having the server generate tokens on each page load and store it. When the user sends the form back, the application can check the token to see if it matches. XSRF hackers will not have access to the token value. One other defense is to require the user to re-authenticate before performing sensitive transactions.

2.6 Security Misconfiguration

2.6.1 Overview

Security misconfiguration or an insecure configuration is a broad topic that deals with infrastructure, system hardening, secure system configuration and patch management. The result of insecure configuration can be server compromise or data compromise.

Server configuration is unique for most organizations. Even within an organization, server configuration needs may vary. This is because many organizations can have different build requirements for the software that they deploy.

An example of an insecure configuration is a software product that comes shipped with default admin accounts with weak or default passwords. If the software is rolled out but the default admin account and password were never changed, then, it becomes a vulnerability that’s just waiting to be exploited. Along the same line of default/weak passwords are old user accounts belonging to ex-employees but the accounts were never deleted.

Insecure configuration problems boils down to a general lack of security hardening policies and IT security management process which could result in issues in configuration like software being rolled out without up to date security patches, server operating system being outdated and missing essential security patches, default admin accounts shipped with off the shelf software not being deactivated, or even old accounts that are no longer needed remaining active in the system. All situations can eventually lead to an attack in the future.

An example scenario where an insecure configuration leads to an attack is a hacker who uses available tools to find servers with vulnerabilities. An example of such tool is Metasploit, a freely available tool containing exploits for different software vulnerabilities. Armed with such tools, they might find an old and server with missing security patches and documented vulnerabilities. They can then have the tool execute the exploit on the server. The damage they can cause depends on the vulnerability being exploited. For instance, it might be a vulnerability that would allow them to gain shell access to the server and do as they please

2.6.2 Real Life Example

In May 2002, a worm named SQLsnake compromised a lot of SQL servers in multiple organizations around the world. The worm performed network scans on port 1433 which is the default port used by Microsoft’s SQL database. Once a SQL server was identified, the worm attempted to login as the administrator using a brute force password cracker. More than 1400 systems were compromised, indicating such systems either had weak passwords or worse, had the default “sa” admin account with the default password of “null” (i.e., no password).

http://www.securityfocus.com/news/429

In May 2009, a disgruntled ex-employee attacked computer systems in his former employer’s network, presumably using his old username and password.

http://www.fbi.gov/minneapolis/press-releases/2009/mp051909.htm

2.6.3 Defenses

Some defenses that can be used against insecure configuration problems are:

Repeatable Hardening Process.
Centralized Patch Management.
Centralized Identity Management.
Regular Updates and Audits.

Hardening of security configuration should be performed on all servers. More importantly, there needs to be a documented process for each server type, software and build in an organizations environment. A documented hardening process would allow administrators to reproduce the same hardened configuration on each operating system or server type.

A good inventory and central patch management is key to keeping all systems in an organization updated. Without a central patch management process, it is very easy to forget to patch an old server, leaving it vulnerable to an attacker who could exploit vulnerability. Without a good system inventory, it would be very easy to lose track of systems and their current patch levels. Note that patch management applies to software as well, not just operating systems.

Centralized identity management can improve user account management. It can minimize situations where accounts belonging to an off-boarded resource are kept active on multiple systems and applications.

Last but not least, one other good defense against insecure configuration is to perform regular system audits. The purpose of such audit is to ensure that patch levels and software versions are up to date. Business Owners could also be required to sign off on their required software and its continued use.

2.7 Insecure Cryptographic Storage

2.7.1 Overview

When dealing with sensitive data, an application needs to not only securely transmit it, it also needs to be securely stored. What piece of information is considered as sensitive data depends on the organization. For instance, username and password should be considered as sensitive data by all applications. For an online shopping site, it probably would consider all customer information, credit card numbers, order numbers and details as sensitive data. A banking site would treat account numbers as sensitive data as well. To an IT Administrator, system and application backups would be considered as sensitive data. To put a generic definition on what sensitive data is, it can be thought of as any piece of information that can cause any form of damage to the organization or its customers if it gets into the wrong hands.

An example of this vulnerability is an application developer who might store sensitive information such as credit card numbers in the database as plain text. They might be thinking that the data is safe because the database is inside their network. Unfortunately, when a hacker does break in to their database, perhaps through a SQL injection attack, all that sensitive information is there for the taking. If the application developers employ an encryption mechanism to store sensitive data, then a hacker might break into the database, but it would require more effort to understand the encrypted data

When it comes to encryption mechanisms, it is very important to choose one that has very strong encryption techniques. For instance, XOR is a simple method to scramble data. Unfortunately, it is something that a hacker can easily break. All they would have to do is provide their own data and have it scrambled by the application. At that point, they would have the original and scrambled values and can easily determine the key.

2.7.2 Real Life Example

In December 2008, a retailer giant, TJ Maxx (TJX), lost over 94 million customer profiles and credit cards due to insecure storage and transmission of data. TJX didn’t use appropriate standards for WIFI encryption and they also didn’t encrypt sensitive customer data per Payment Card Industry (PCI) standard requirements. Hackers sat outside TJX stores where there was a WEP protected WIFI network. WEP is a wireless protocol with known weaknesses and the hackers were able to crack the security and jump into TJXs corporate network. Once inside TJXs network, they found the databases and determined that credit card numbers including the CVC code were stored in plain text. They were able to breach the database through the WIFI weakness point and steal millions of credit card and customer information.

http://www.informationweek.com/news/201800259

2.7.3 Defenses

A few best practices can help in ensuring data security:

Threat modeling exercise.
Use of known strong algorithms.
Password hashing.

Determine what sensitive data to the organization is early on in any application development project. What kinds of information needs to be protected within the organization (passwords, order details, account numbers, personal health data). The kind of information that needs to be protected will affect the security levels required to protect confidentiality. Identifying this at an early stage is important to ensure that the data is protected throughout the architecture of the application.

The process of threat modeling, specially if done at an early stage, can be extremely important to determining what information needs to be protected in the application. In a threat modeling exercise, data assets are classified and for each type, the vulnerabilities are identified. When vulnerabilities have been identified, the threats and likelihood of such attack can be assessed. Defenses for each type of threat can be then put into account during the project lifecycle. Threat modeling can help organizations identify what data needs protection and whether the risks warrant those safeguards. It is a very important part to project management from a risk standpoint.

When encrypting sensitive information it is very important to use a well-known strong algorithm and keys. Also, passwords should always be hashed before storage in a database. Use of one way hashing algorithms such as SHA256 should be considered. One way hashes are easy to implement but very difficult to reverse.

2.8 Failure to Restrict URL Access

2.8.1 Overview

Failure to Restrict URL Access results in forcible browsing. A Forcible browsing vulnerability will provide a hacker unauthorized access to areas of a server or application. The cause of such vulnerability is usually due to misconfiguration of web server permissions or inadequately programmed application logic. Forcible browsing can provide users or hackers with unauthorized access to data and can also result in access to functionality outside their normal permission levels.

A hacker performs a forcible browsing attack on a website by browsing to web pages that they believe or “guess” that might exist on a website. For example, a website might have a main entry point URL like this:

http://www.demo.xyz/homepage.asp

A hacker might guess that maybe there’s an admin page somewhere within the application. So some URLs that they might forcibly browse to are:

http://www.demo.xyz/admin.asp
http://www.demo.xyz/config/admin.asp

While a normal user might not have any means to get to the admin pages through the use of the application, there’s nothing that stops a hacker from typing in the URLs directly into the browser’s address bar, hence, forcible browsing. If the web application does not have any logic behind it to protect the page, the hacker might just be able to access and perform admin tasks as a regular user.

2.8.2 Real Life Example

In June 2010, Blue Cross became victim to a forced browsing vulnerability. Customers were able to forcibly browse to other Blue Cross customers’ insurance profiles. By directly visiting URLs, it exposed over 230,000 sensitive personal insurance profiles resulting in Blue Cross having to notify the affected customers and a lot of negative publicity.

http://www.ocregister.com/articles/information-254735-security-anthem.html

2.8.3 Defenses

A couple of best practices can help defend against forcible browsing vulnerabilities:

Page level authorization.
Programmed authorization.

The application server, either through web server configuration or operating system controls can be configured to stipulate whether access to certain files is restricted or allowed. One possible problem with this approach is that for large applications, it could require a significant effort to correctly configure security for multiple pages. Also, page level authorization is sometimes not enough, for example, when more granularities are required. That’s because it can be used only to say who has access to the page and who doesn’t. Page level authorization does not have any means to stipulate what users can do on the page.

The next defense against forcible browsing is programmed authorization. This means that security logic is embedded within the application. This would allow for much more granularity than page level authorization. Through the use of code, an application developer can define what each permission level can do in any page within the application.

2.9 Insufficient Transport Layer Protection

2.9.1 Overview

Traffic on a network can be intercepted and read by computers on the network other than the sender and receiver (particularly over unencrypted open Wi-Fi). This traffic includes cookies sent on ordinary unencrypted HTTP sessions. Without any protection in the network transport layer, a hacker can simply run a network traffic sniffing tool and literally eavesdrop on communication that goes through the network. Any information transmitted in plain text can be easily read by the hacker.

2.9.2 Real Life Example

In October 2010, a new Firefox addin named Firesheep allowed users to view and hijack others’ sessions on popular sites like Facebook, Twitter, Amazon, etc. and impersonate the victim.

http://securitywatch.pcmag.com/apple/283724-with-firesheep-all-your-http-sessions-belong-to-us

2.9.3 Defenses

The primary defense against this vulnerability is to employ transport layer security (HTTPS protocol) to encrypt the connection.

Always on SSL.
Avoid a weak SSL implementation.

If an application is transmitting sensitive information over the internet, it is always best to use SSL encryption. SSL encryption is the accepted standard for encrypting data in transit.

Deciding to use SSL is the first step in securing communications between an application and its clients. There are some aspects to implementation that needs to be considered as well. For instance, weak ciphers that operation under 128 bits should be avoided. Also, older versions of SSL (v1, v2) should be avoided as they have known vulnerabilities. If an application deals with very sensitive data (such as banking applications), consider disabling HTTP access altogether and only serve the application pages through HTTPS.

2.10 Unvalidated Redirects and Forwards

2.10.1 Overview

URL redirection is a mechanism used by developers as a way to forward users automatically to other pages within the application (or other domains within the company) after the user has performed certain actions. Oftentimes, a url parameter is used to determine the destination of the redirect. For example:

http://www.demo.xyz/redirect.jsp?url=accountdetail.jsp

Unfortunately, this url redirect is very visible and very easy for a hacker to modify. A hacker only needs to type in a different url and see how the application responds. If the application does not validate the target URL on the server side, a hacker could use it to redirect users to other sites. Since the URL begins with the company’s website, it tricks the user into trusting the link and will more likely click it, not recognizing that there is a url parameter that would lead them to a different site. For example:

http://www.demo.xyz/redirect.jsp?url=hackerdomain.xyz\hacked.jsp

Some users might be careful enough to catch that even though they recognize and trust the demo website, the link appears to be a trick to get them to the malicious site. A hacker can easily mask their website by picking a less revealing domain name, or by using URL shortening services like bitly.com. For example:

http://www.demo.xyz/redirect.jsp?url=bit.ly/90p13p

Now the URL is less suspicious and the fact that it’s coming from the organization’s “trusted” domain, a user is more likely to trust and click it.

2.10.2 Real Life Example

In April 2010, hackers were able to exploit a unchecked URL redirect vulnerability on CNN’s ad server. They masked the site name using bit.ly, the url looked like this:

http://ads.cnn.com/event.ng/Type=click&Redirect=http://bit.ly/cP-XW

Coming from a trusted website and nothing in the URL looks suspicious; this tricked a lot of users into clicking it. Clicking the URL took the users to an auction listing employment agency scam site. The site was designed by the hackers to have the look and feel of a news agency site that might be sponsored by CNN. Since the link “came” from CNN, users would think that they are browsing a legitimate site that CNN endorses.

http://blog.commtouch.com/cafe/email-security-news/cnn-redirect-exploited-by-scammers/

2.10.3 Defenses

A couple of defenses against unchecked url redirect attacks are:

Don’t use url parameters.
Server side validation.

The best defense is to not use url parameters at all. Store url redirects in session variables instead or do the redirection within code. Hackers will have no way of tampering with the url redirect if it remains on the server side. If URL parameters cannot be avoided, the next line of defense is to have some sort of server side validation performed. The application must validate that the url in the redirect is acceptable and authorized for the user. For example, have a white list of all approved domains or pages. Any URL redirect parameter that does not fit the whitelist should be dropped.

3. Useful WebSEAL Features and Configuration

3.1 Overview

WebSEAL can be used as a protective front end to an application. It can perform authentication and authorization checks on all requests before passing those requests on to the back-end server. Administrators can benefit from the centralized management of their organization’s web space. Below are features and configurations of WebSEAL that can be used to prevent or minimize risks in web applications.

3.2 URL String Filtering

By default, WebSEAL filters URL strings that contains <script. That means, if WebSEAL encounters <script in a URL request, it will return a 400 “Bad Request” error page.

If additional filtering is required, an [illegal-url-substrings] stanza could be used in the WebSEAL configuration file to identify string fragments to be filtered. For example:

[illegal-url-substrings]

Substring = <script

Substring = <applet

Substring = <embed

If WebSEAL detects any of the configured string fragment in a URL request, WebSEAL will consider it an illegal request and not accept it. WebSEAL will return with a 400 “Bad Request” error page.

In addition to the above, WebSEAL also encodes angle brackets (< >) in redirected URLs. The encoding can help prevent normal interpretation of scripts by the browser.

3.2 Suppressing WebSEAL and Back-end Application Server Identity

HTTP responses normally include a server header containing the identity and version of the server that is sending the response. A typical response from WebSEAL might look like:

Content-Type: text/html

Date: Tue, 09 Nov 2011 02:34:18 GMT

Content-length: 515

Server: WebSEAL/6.0.0

Last-Modified: Thu, 04 Nov 2011 08:03:46 GMT

Connection: close

A typical response from a back-end server might look like:

Content-Type: text/html

Date: Tue, 09 Nov 2011 03:34:18 GMT

Content-Length: 515 Server: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Win32) Last-Modified: Thu, 04 Nov 2011 09:03:46 GMT

Connection: close

For security reasons, WebSEAL can be configured to suppress the server identity from the client. By not revealing the server identity, hackers would not know the operating system and web software behind the application. Hackers would not be able to use exploits that are based on specific system or software patch levels.

To suppress WebSEAL server identity in the HTTP server responses, the suppress-server-identity stanza entry in the [server] stanza of the WebSEAL configuration should be set to “yes”. To suppress back-end application server identity in HTTP server responses, the suppress-backend-server-identity stanza entry in the [server] stanza should be set to “yes”.

[server] suppress-server-identity = yes

suppress-backend-server-identity = yes

3.3 Reauthentication

WebSEAL can force a user to perform an additional login (reauthentication) to ensure that a user accessing a protected resource is the same person who initially authenticated at the start of the session. Forced reauthentication provides additional protection for sensitive resources in the secure domain.

Reauthentication can be activated by:

A protected object policy (POP) on the protected object.
Expiration of the inactivity timeout value of a WebSEAL session cache entry.

Reauthentication is supported by the following WebSEAL authentication methods:

Forms (user name and password) authentication.
Token authentication.
External authentication interface.

During reauthentication, WebSEAL also caches the request that prompted the reauthentication. Upon successful reauthentication, the cached data is used to rebuild the request. If reauthentication fails, WebSEAL returns the login prompt again. If reauthentication succeeds, but the ACL check fails for that resource, a 403 error (Forbidden) is returned and the user is denied access to the requested resource. In either case, the user is not logged off unless the max-login-failures policy limit has been reached. Using a still valid credential, the user can terminate the reauthentication process (by requesting another URL) and still participate in the secure domain by accessing other resources that do not require reauthentication.

4. Reference

The Top 10 Risks and a lot of other related information can be found in the Open Web Application Security Project (OWASP) website:https://www.owasp.org/index.php/Main_Page. OWASP is an open community focused on enabling organizations to conceive, develop, acquire, operate and maintain applications that can be trusted.

Web App Security: Defending Against the Top 10 Risks

Services

Solutions

Pricing

Resources

Events

About Us

Get Started