Calling users donkeys and other security woes of AJAX
Connecting state and local government leaders
Asynchronous JavaScript and Extensible Markup Language brings new capabilities to Web apps, but it can also lead to new dangers.
AJAX, or Asynchronous JavaScript and Extensible Markup Language, brings exciting new capabilities to Web applications, but it can also lead to new dangers, industry observers say.'The biggest problem with AJAX is that it creates an entirely new attack surface for people,' said Scott Morrison, chief architect at Layer 7 Technologies, which offers appliances for securing and accelerating XMLbased content over networks. With simple Web pages, the intelligence lies in the Web server. But AJAX is asking the browser to do more of the heavy lifting, he said, and developers all too often fail to put security measures in place to safeguard these complex interactions.'AJAX is predicated on having this JavaScript engine running on the browser for pulling out information from the back end. The problem is [that] those engines tend to be written by developers quickly'to solve problems,' Morrison said. Little thought is put into screening what kind of data the browser handles.Perhaps the chief problem is cross-site scripting, abbreviated as XSS. In a presentation at last year's JavaOne conference in San Francisco, VeriSign engineer Karthik Shyamsunder showed how a cross-scripting attack could work.A malicious hacker could write a JavaScript code that could, in theory, insult the user by having the browser generate a pop-up box that called the user a donkey, such as:This JavaScript could be placed within any Web page. A trickster could lure the user ' via an e-mail from a trusted address, for instance ' onto a commonly visited site that accepts user input, such as one that invites comments or asks for the user's name to personalize the Web page.If the server does not limit the types of data it allows as input, a script could be submitted that the server would, in turn, pass along to the user's browser.Perhaps the server accepts input on how to personalize the Web page it will return to the user. This could be done within the Web address itself:The trickster could format the address sent to the server to hold the malicious script rather than the name of the user:The upshot is that when the user unwittingly submits the link request to the server, the Web server generates a customized Web page that executes the malicious script and calls the user a donkey.Of course, far more damage could be done than just hurling insults. Shyamsunder's demonstration showed how a badly configured Web application opens a hole for actions unintended by the Web site owner.Web developers can easily put measures in place to thwart such behavior, Shyamsunder said. A chief strategy is to limit the kinds of input Web servers can accept.For instance, characters commonly used to generate JavaScript and SQL queries could be prohibited, such as dollar signs, ampersands, question marks and asterisks.Another technique would be to encrypt data traveling between the browser and the server to thwart such man-in-the-middle attacks.XSS is nothing new. It predates AJAX and has been around as long as JavaScript ' but AJAX reinvigorated the danger of XSS.(For a review of how XSS works, see GCN.com GCN.com/889.) Webmasters have been securing their servers against such attacks ' and protective measures have been put in place on the browser side, too ' but less has been done for new Web technologies such as AJAX.AJAX opens new avenues for entry of malicious data into the browsing environment ' especially because AJAX pages can reconfigure themselves without input from the server. In his book 'XSS: Cross Site Scripting Attacks,' WhiteHat security founder Jeremiah Grossman explained that Web developers often don't have skills in security that would allow them to bulletproof their Web applications, most notably by providing some mechanism to ensure that user input conforms to the appropriate format.That failure 'persistently backdoors the remote application. From this point on, attackers can do whatever they feel like with your on-line presence,' Grossman wrote.
- < script> alert('You%20are%20a% 20Donkey');< /script>
- http://www.hackmebank.com/welcome.jsp?name=John
- http://www.hackmebank.com/welcome.jsp?name=
NEXT STORY: Microsoft's token participation