| |
|
This page contains all of the posts and discussion on MemeStreams referencing the following web page: WhiteHat Security :: Articles. You can find discussions on MemeStreams as you surf the web, even if you aren't a MemeStreams member, using the Threads Bookmarklet.
|
WhiteHat Security :: Articles
by Lost at 1:47 pm EST, Dec 1, 2006 |
The hype surrounding AJAX and security risks is hard to miss. Supposedly, this hot new technology responsible for compelling web-based applications like Gmail and Google Maps harbors a dark secret that opens the door to malicious hackers. Not exactly true. Even the most experienced Web application developers and security experts have a difficult time cutting through the buzzword banter to find the facts. And, the fact is most websites are insecure, but AJAX is not the culprit. Although AJAX does not make websites any less secure, it’s important to understand what does. AJAX (Asynchronous JavaScript XML) is a combination of web browser technologies that allows web page content to be updated “on-the-fly” without the user moving from page to page. In the background of an AJAX-enabled web page, data (typically formatted in XML, but also HTML, JavaScript, etc.) is transferred to and from the web server. In the case of Gmail, new email messages are displayed as they arrive automatically. In Google Maps, a user may mouse-drag through street maps without visiting additional pages. The mechanism for performing asynchronous data transfers is a software library embedded in all modern web browsers called XMLHTTPRequest (XHR) . XHR is the key to a website earning the “AJAX” moniker. Otherwise, it’s just fancy JavaScript. If you’re thinking that none of this sounds security related, you’re right. AJAX technology makes website interactivity smoother and more responsive. That’s it. Nothing changes on the web server, where security is supposed to reside. If that’s the case, then what is everyone talking about? Word on the cyber-street is that AJAX is the harbinger of larger attack surfaces, increased complexity, fake requests, denial of service, deadly cross-site scripting (XSS) , reliance on client-side security, and more. In reality, these issues existed well before AJAX. And, the recommended security best practices remain unchanged. If you’re like me, you want to know what’s really important, so let’s take a closer look.
I know a memestreamer is writing a book on this stuff, so I'm interested in his comments on this. |
| |
Myths of Myths of Myths: Ajax and security
by Acidus at 8:54 pm EST, Dec 2, 2006 |
Jello wrote: I know a memestreamer is writing a book on this stuff, so I'm interested in his comments on this.
This was an interesting article, and while I don't agree with it all of it, it does points out a big problem many in the web industry are guilty of: use of the word Ajax. Ajax is basically XmlHttpRequest, JavaScript, and XML. These are not insecure by themselves. End of story. However, when most people talk about Ajax, they tend to (perhaps incorrectly) use it as a catch all when discussing web applications that exist on the client and the server that use XmlHttpRequest (XHR) to provide a rich user experience. Sounds vague, maybe I can get some VC for that! However, there are security issues that arise when an organization uses various technologies to make there websites more responsive, when creating mashups, etc. Are they new security issues? No. Does that mean talking about Ajax in the context of security is silly because it is "nothing new?" Of course not, because frankly there haven't been a "new" security issue that wasn't discussed in the godfather of security tomes: Security, Accuracy, and Privacy in Computer Systems (Martin, 1973). There's a reason why my articles and talks have been titled "Ajax (in)security." It covers Ajax in (the context of) security as well as stupid, insecure ways people have used Ajax. So why talk about Ajax security at all? To make sure people know about how security applies in applications that straddles the client and server. To make sure that they think twice about what the library or framework or product that makes their website prettier and more responsive actually does. To make sure people are extend their good security practices to rich interfaces. It is not Ajax's fault and it is not about finding problems with Ajax that exist no where else. It's talking about security as it applies to a new technology and that is not something to criticize or dismiss because it sounds unoriginal. Here are my thoughts: Does Ajax cause a larger attack surface: It depends This really should just say “rich interface tends to increase the attack surface, Ajax included.” The article even says: “AJAX drives developers to publicly expose more functionality - which may introduce new “server-side” vulnerabilities.” Exactly, more inputs that need to be secured against traditional attacks, AKA, a larger attack surface. Is this Ajax's “fault?” Its no one's fault, just like opening a service for a Flash stock ticker to fetch prices from isn't Flash's fault. There is a cost for that rich interface, and that cost is more inputs. It comes done to how the application is designed. Is a search engine's dialog box going to have more attack surface if the app is submitting that using XHR than a POST? No. But a search engine's dialog box that has a dynamically populated drop down box of words with a drop down like... [ Read More (0.4k in body) ] |
|
| | |
RE: Myths of Myths of Myths: Ajax and security
by Lost at 11:44 pm EST, Dec 2, 2006 |
Acidus wrote: Jello wrote: I know a memestreamer is writing a book on this stuff, so I'm interested in his comments on this.
This was an interesting article, and while I don't agree with it all of it, it does points out a big problem many in the web industry are guilty of: use of the word Ajax. Ajax is basically XmlHttpRequest, JavaScript, and XML. These are not insecure by themselves. End of story. However, when most people talk about Ajax, they tend to (perhaps incorrectly) use it as a catch all when discussing web applications that exist on the client and the server that use XmlHttpRequest (XHR) to provide a rich user experience. Sounds vague, maybe I can get some VC for that! However, there are security issues that arise when an organization uses various technologies to make there websites more responsive, when creating mashups, etc. Are they new security issues? No. Does that mean talking about Ajax in the context of security is silly because it is "nothing new?" Of course not, because frankly there haven't been a "new" security issue that wasn't discussed in the godfather of security tomes: Security, Accuracy, and Privacy in Computer Systems (Martin, 1973). There's a reason why my articles and talks have been titled "Ajax (in)security." It covers Ajax in (the context of) security as well as stupid, insecure ways people have used Ajax. So why talk about Ajax security at all? To make sure people know about how security applies in applications that straddles the client and server. To make sure that they think twice about what the library or framework or product that makes their website prettier and more responsive actually does. To make sure people are extend their good security practices to rich interfaces. It is not Ajax's fault and it is not about finding problems with Ajax that exist no where else. It's talking about security as it applies to a new technology and that is not something to criticize or dismiss because it sounds unoriginal. Here are my thoughts: Does Ajax cause a larger attack surface: It depends This really should just say “rich interface tends to increase the attack surface, Ajax included.” The article even says: “AJAX drives developers to publicly expose more functionality - which may introduce new “server-side” vulnerabilities.” Exactly, more inputs that need to be secured against traditional attacks, AKA, a larger attack surface. Is this Ajax's “fault?” Its no one's fault, just like opening a service for a Flash stock ticker to fetch prices from isn't Flash's fault. There is a cost for that rich interface, and that cost is more inputs. It comes done to how the application is designed. Is a search engine's dialog box going to have more attack surface if the app is submitting that using XHR than a POST? No. But a search engine's dialog box that has a dynamically populated drop down bo... [ Read More (0.4k in body) ]
|
|
| | |
RE: Myths of Myths of Myths: Ajax and security
by Decius at 1:34 am EST, Dec 3, 2006 |
Thanks for this insightful commentary! However, I have to say.... My pseudo mullet in elementary school was a mistake that my mom should never have let me make, regardless of how cool MacGyver was.
Wow.... Just... Wow.... |
|
|
|
