Web Injection

8/13/2019 Web Injection

1/3Network Security March 2006

8

WIRELESS LAN

What is code injection?The ability to successfully exploit a codeinjection/insertion attack is based upon thefunctionality provided by the users browser.All browsers will interpret the overwhelmingmajority of instructions in a similar manner,however discrepancies in the handling ofesoteric code may result in a radically differ-ent outcome between Internet Explorer and,

say, Firefox. This article will focus upon thecommon cross browser insertion methodsavailable, with the occasional mention ofbrowser-specific issues.

The content received by a client from aweb server will have specific commandswithin the HTML that will control itsappearance, commands such , and . More interest-ing functionality can introduced with othercommands such and

. It is these HTML commandsthat are typically abused in order to performa code insertion attack, each having a differ-ent purpose:

SCRIPT Implements a script withinthe page, typical examples areJavaScript or VBScript.

APPLET Inserts a Java applet withinthe page.

EMBED/OBJECT Inserts an object,typically multimedia into the page,EMBED has been phased out inHTML 4 in favour of OBJECT.

FORM Used to indicate the start

and end of a form which would becompleted by the user.

Whilst these HTML tags will be thetypical targets of a malicious user, it shouldbe kept in the mind that inline scriptingmethods can be abused as well i.e.javascript:alert(test).

All code injection attacks vary consider-ably depending on their delivery methodwhich in turn would alter their affectedaudience: An attack against your personal details

page of an online store would affectyou and any admin personnel thatmay be required to view your details,however other users are unlikely to beaffected.

Posting a message to a public forumwith a malicious scripting element willlikely affect any user visiting that page.

Failed URL access attempts with mali-cious code may appear redundant,however may prove a valid attack vec-tor should an administrator be using aHTML compliant log viewer.

Cross site scriptingA very popular code insertion attackmethod is Cross Site Scripting. It is verycommon to find site search scripts vulnera-ble to this particular attack A typical attackwhich may arrive via an email may be alink such as the following:

searchexample.com

This form of attack is especially nasty as itcan be trivially deployed to the intended vic-tim through a link in an email or on a webpage, appears to originating fromwww.example.comand as the exploit code resides upona remote site the attacker retains control overits content and can remove it at any point.

A common means of testing your sites sus-ceptibility to this attack, and one you willlikely have witnessed in any applicationassessment report is the following safely exe-

cutable code:www.site-to-be-

tested.com/script.pl?param=blaalert(vuln)

Web Injection Attacks[[whereexamplesofcodingappearinaseparateline,canweputitthemanotherfont?]]David Morgan

This article will be the first in a series that will review web application secu-rity issues and provide suggestions on how to avoid the classic pitfalls. Thisparticular article will discuss code injection and specifically cross site script-ing. Injection into application elements other than the web server and theclient (i.e. SQL injection) will be discussed in later articles.

usability of security technologies, and details ofother related papers can be obtained fromwww.plymouth.ac.uk/nrg.

Dr Bogdan Ghita is a senior lecturer withinthe Network Research Group at the Universityof Plymouth, where he has supervised a num-

ber of projects relating to the use and securityof Wireless LAN systems. Dr Ghitas widerresearch interests encompass a range of net-working and security-related issues.

(i) Khan, J. and Khwaja, A. 2003.Building secure wireless networkswith 802.11, Wiley, Indianapolis.

(ii) Wi-Fi Alliance. 2002. Wi-FiAlliance Announces Standards-BasedSecurity Solution to Replace WEP,Press Release, Wi-Fi Alliance, 31October 2002. http://www.wi-

fi.org/OpenSection/ReleaseDisplay.asp?TID=4&ItemID=118&Str

(iii) Stats page, The Official WorldWideWarDrive website, http://www.world-widewardrive.org/wwwdstats.html(accessed January 2006).

(iv) Belkin. 2003. Belkin Wireless AccessPoint User Manual F5D7130,http://www.belkin.com/support/download/downloaddetails.asp?file_id=1113 (accessed January 2006)

(v) Belkin. 2003. FAQ: What is Wi-FiProtected Access?, Belkin KnowledgeBase 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 XtremeG DWL-2100AP 802.11g Wireless108Mbps Access Point - Manual,ftp://ftp.dlink.com/Wireless/dwl2100AP/Manual/DWL-2100ap_manual_06292005.zip (accessed January 2006)

(vii) Linksys. 2005. Wireless-G Access PointUser Guide WAP54G.

http://www.linksys.com/servlet/Satellite?blobcol=urldata&blobheadername1=Content-Type&blobheadername2=Content-Disposition&blobheadervalue1=application%2Fpdf&blobheaderval-ue2=inline%3B+filename%3DWAP54G-v3_ug.pdf&blobkey=id&blobtable=MungoBlobs&blobwhere=1126990060705&ssbinary=true (accessedJanuary 2006)

(viii) Netgear. 2005. Reference Manual forthe NETGEAR 54 Mbps WirelessAccess Point WG602v3, February2005, 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-4aaa01rev01.pdf (accessed January 2006).

WEB INJECTION ATTACKS
http://www.example.com/http://www.example.com/http://www.example.com/http://www.example.com/http://www.example.com/


2/3

March 2006 Network Security9


Should this particular script and para-meter be susceptible, a popup box withthe text vuln will appear within thebrowser when executed. With complicatedscripts each parameter would requirechecking individually.

The cross site nature of this attack is due

to the ability to break the security restric-tions of the client browser. For exampleyou may have a configuration that allowsthe execution of scripts from your Intranetsite but not from others. This attackwould allow the execution of a maliciousscript from a 3rd party site as it is executedas if it came from the Intranet site.

The previous examples relied on a userclicking upon a link. However, further validattack vectors include abuse of the HTMLtags such IMG and IFRAME which wouldbe automatically executed when the page is

viewed. The most common use for theseattack vectors by malicious individuals is tosteal user authentication and session manage-ment cookies. An attacker would send a linkto their victim with a link to a vulnerable sitethe user visits and has a cookie for. The mali-cious script would include code to send thecookie to the malicious users site. Theattacker is now in a position to access thevulnerable site as the victim user with theircookie acting as authentication. An exampleattack could take the following form:

Mitigating against codeinsertionThe key to successfully preventing codeinsertion attacks is appropriate filtering,not always an easy task with what could be

extensive and complicated input require-ments. The first stage of implementing asuccessful filter is to assess the data inputrequirements - for example a phone num-ber field would only require digits, andname fields would only require the alpha-bet and possibly the hyphen. Fields requir-ing more complex data such as search, orfree text, boxes will often require allowingthe majority of characters whilst excludingknown bad characters, examples of whichinclude:

; / \ ? : < > # [ ] { } ( ) ~ % ^ | @ =

There is no off the shelf filter that is guar-anteed to prevent code insertion attacks, a

responsible developer would need to restrictthe allowed input only to those charactersrequired, and then to test the filter in a num-ber of ways to ensure it is effective.

An often encountered means of inter-preting these special characters within webapplications is to the HTML escape

encoding of them, for example the < char-acter becomes %3c. An attacker could usethis encoding scheme to bypass filteringroutines, for example a filter may look forand remove the characters < and > fromany supplied data to prevent the often-abused and tags.An encoded attacker would successfullybypass the filter with a string such as%3cSCRIPT%3e.

Wherever possible,

scripts should beconfigured to utilisethe POST method andthe GET methodshould be disabled

In other cases an application may identi-fy the presence of a script and prior todelivering it to the client would commentit out to prevent execution. An example

page presented to the user may look like:

Malicious codealert(vul

n)remainingparams=aaa

This would require a user to visit thepage themselves and enter the exploitcode, it would not possible to entice themail to be tricked via an email for exam-ple. However the same POST could beconverted to a GET request and thereforeinto a URL which could be sent to unsus-pecting users:

http://www.example.com/Search?vari-able=Search&a=\>alert(vuln)remainingparams=aaa

Wherever possible, scripts should beconfigured to utilise the POST methodand the GET method should be disabled.


3/3

Network Security March 200610


These guidelines do not claim to be com-prehensive, but are focused on the most crit-ical areas every enterprise needs to adopt from running Secure Sockets Layer (SSL) onservers to supplying client side SSL certifi-cates to employees, to establishing solid poli-

cies and procedures for security and embrac-ing paperless transactions.

Without SSL encryption, the integrityof data exchanged over public and private

networks can be compromised, ultimatelyaffecting business continuity and the bottomline. SSL safeguards network access, onlinecommunications and digital transactions byenabling a secure channel between serversand users. It is the most widely deployed

security protocol in the world, and webelieve it should be deployed on any and allservers to protect any confidential and per-sonal information that is passing from

browser to server. It is used today to secureweb sites, intranets, extranets and otherserver-based applications.

Awareness and understanding of the bene-fits of SSL technology has expanded consid-erably over the past several years. More andmore users, both professional and non-pro-fessional are looking for the lock symbol intheir browser indicating that a session isencrypted with SSL.

Millions of sites have installed the X.509special server digital certificate that activatesSSL between browsers and servers. The sup-port for SSL is already built into all modernweb browsers and servers so all that is neededfrom the enterprise perspective is the simpleinstallation of the certificate on the server.Once the browser and server perform theirhandshake, all data transmitted from one tothe other is encrypted, preventing any eaves-dropping that might jeopardise the securityor integrity of the data transmission.

PKI has moved onPublic Key Infrastructure (PKI) is a tool toenable online applications to be used in ways

Securing onlinebusiness with SSLSteve Waite, Director, GeoTrust Europe

While it has become more convenient to dobusiness online, it has also become more difficultto ensure reliable and secure data exchange andcommunications. Continually evolving securitythreats and changing regulatory standards can make maintaining a trustedonline environment a challenge for any size enterprise. In this article, wellprioritise our recommended security practices for building online trust bothinside and outside your enterprise.

Surprising scenariosWeb Application developers create applica-tions to be utilised by web browsers. Oftenan assumption is made that people will beusing a particular browser, or, as some-times is the case, browser specific featuresare utilised. It is however imperative that

the application be tested with all the com-monly available browsers as strange thingscan happen when you assume too much.

Internet Explorer for example does notrequire the special character > to close twoof the common HTML tags; IFRAMEand IMG, this is the case as the browserwill automatically add them when thepage is viewed by the user. NGS, uponassessments, has come across filtering codewhich will remove all user supplied datathat appear between the characters < and

>, as you imagine this is pretty effectiveuntil you appreciate the significance of thetwo previously mentioned tags. A classicattack may be as follows:

http://www.example.com/vuln.pl?var=

This would however not execute aseverything between the < and > tags isremoved. However as we can leave off the

trailing > the following code would work(it no longer matches the filter):

http://www.example.com/vuln.pl?var=

Web Injection

Documents

Transcript of Web Injection