Hi folks, Only catching up on emails now, but I want to make some comments on the articles Gervas was quoting that seemed to imply Ajax being more of a security threat than other things.
On Fri, 2006-06-09 at 10:38, Gervas Douglas wrote: > "If an attacker can figure out your Ajax data request layout, which > depends on factors such as the type of data being requested and the > permissions needed to access data, they can figure out how to access > data without having the authorization to do so," says Basirico, who > spent two years as a programmer with Microsoft. This quote seems to indicate that it's rocket science to "figure out your Ajax data request layout". It isn't, because you are required to provide all of the Ajax manipulation code to the client. If you're interested, you just view the source of the page to see the script links included and download the source of all of the JavaScript used for the site. If the browser can see it, the person behind it can see it. >From an authentication point of view, if you require authentication checks for all sensitive resources, you can ensure that only authorized users can access specific URLs. However, the crux of technologies like Ajax which are built on JavaScript and XmlHttpRequest is that if the browser has an authenticated session (and for Netscape/Mozilla, this is *any* window you have open because sessions are shared), any code executing in the browser also shares this authentication context. The issue isn't the attacker "figuring out your Ajax requests" so much as being able to establish a covert channel between something they control and something controlled by the authenticated session of another user. Once this channel is established, they are executing code as the intended user. It's similar in concept to what attackers try to do with a buffer-overflow exploit: execute their code as another user who has more privileges than they do. > But attacks within Ajax environments are already a reality. A teenage > programmer known as "Samy" last year inserted code in his MySpace Web > site user profile so that those viewing his profile would have their > own profiles corrupted. "The MySpace hack was the first Ajax worm and > consisted of a cross-site script that automatically added [Samy's] > profile to the friends list of many MySpace users," says Caleb Sima, > chief technology officer of Spi Dynamics, a provider of Web > application security and testing technology. This attack resulted from the attacker placing executable JavaScript into a resource which would be loaded by another user. In this case, the attacker's own personal profile page (under their control) provided the covert channel between them and the victim's authenticated session. Since the attacker knew the required sequence of HTTP requests required to edit their own profile, they could cause these to be executed automatically when the page was loaded for any user with content of their choosing. There's nothing magical about Ajax here, the issue is just a pure-and-simple JavaScript problem (shared by any sort of client-side scripting environment). The reason it is important is because Ajax is becoming more popular, and this is requiring more users to allow script execution than before. It also means that in large shared sites like MySpace where authenticated users can view content created by others who may be malicious, there is really no easy solution to the issue. Looking at the description of the exploit (full details are here: http://namb.la/popular/tech.html), this sort of technique is why I indicated that most of the simple checks present in XML gateways for SQL injection won't work very well against someone who is clever. Anywhere you can do stuff like String.fromCharCode(x) (and this is an obvious one--not all of the potential ones are this easy to detect), you can generate some pretty obfuscated code. With a little bit more JavaScript, it is easy enough to translate a set of bytes to the appropriate (albeit much longer) "escaped" JavaScript equivalent. The only way to solve the problem is to be able to reliably detect direct and obfuscated JavaScript when the attacker attempts to embed it in the page and stop it there. However, if users are allowed to modify things like page templates as well where JavaScript is often allowed, then the issue just gets moved around. Again, it has nothing to do with Ajax per-se, but is a by-product of JavaScript being used more extensively. The issue still boils down to what the authenticated user is authorized to do via HTTP verbs. If there's no covert channel, there's no exploit. > In an Ajax environment, the application makes frequent calls to a > database, a characteristic that "increases your attack surface," Sima > says. This statement is pretty misleading and is certainly not true of all Ajax applications. > With a more conventional Web application, a user would, for example, > fill out an online form to apply for a new bank account and submit > that form for approval. A programmer could add Ajax or Web services > capabilities to that application by immediately alerting the user if > information is entered improperly in different fields, even before the > form is submitted. "These Web services are all making calls to a > database," Sima says. "Most developers will throw a Web service up, > make a database call that is probably SQL injectable, and have no > session authentication to protect the transaction." > > Such oversights compromise the security of Web applications as well as > the databases they access.>> The above illustrates that there may be a mistaken impression that designing an Ajax application is much different than designing a non-Ajax application. Ajax gives you the ability to provide richer client interfaces, but Ajax is built on JavaScript and XmlHttpRequest, meaning that it can't do anything to the server-side application or database that can't be done via standard HTTP verbs. Ajax doesn't mean that you can shortcut good application interface design and security considerations. The server-side of the Ajax application still exposes a known (and hopefully, well-understood) API via the HTTP verbs and request parameters it supports. If you understand the security exposures for each of these verb/parameter combinations and the potential covert channels for sharing data (and potential exploits) between users, you will understand the exposures to your Web service--with or without Ajax. Exposing a server-side API via HTTP which allows direct data manipulation with SQL is nearly equivalent to writing a CGI script that allows you to execute arbitrary server-side commands. You wouldn't do the latter, so why would you do the former? Ajax isn't a short-cut for developing a well-behaved Web service, but does allow you to provide a more usable Web service. If you or your development team don't understand the distinction, you're going to be headed for trouble from the moment you deploy your service. ast *************************************************************************************************** The information in this email is confidential and may be legally privileged Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *************************************************************************************************** ------------------------ Yahoo! Groups Sponsor --------------------~--> Home is just a click away. Make Yahoo! your home page now. http://us.click.yahoo.com/DHchtC/3FxNAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
