|
As been said before in this thread, AJAX is just another 'architecture'
for creating systems that allow end users to use online services
(although due to the increased attack surface one more potentially
dangerous than an website interface). But will AJAX dramatically increase or decrease the security vulnerabilities that exist in applications? I am not sure. More and more I am convinced that it is the 'development model' / 'development mindset' that has the greater impact in the security of the newly created applications. In an environment where: a) end clients (the ones paying for the development) don't care about (or don't know how to demand) secure applications, b) solution architects have limited time/budget to design a solution to 'ever-moving project objectives/deliverables' c) projects are so complex that nobody has a full technical understanding of the entire system d) there is no (or there is a weak) formal security process (from threat modeling, to secure by design/default/deployment designs, to code audits) e) developers don't have a strong understanding of the security implications of the programing techniques that they use f) developers are given unrealistic deadlines for the number of features requested g) the financial benefit in writing secure code, is much smaller than the financial benefits of writing feature rich applications which have good performance h) security incidents will be 'covered up', not publicly disclosed unless they really have to, and the responsible parties (which in my view, in most of the cases are not the developers) are not made accountable g) the ever changing of technologies used (where nobody really masters it, and even very experienced programmers are most of the time 'professional amateurs') i) the increased complexity and interconnectivity of our systems ...how do you expect secure applications to be developed? Ultimately we must look at the assets and answer the question "are they still being compromised?" regardless if the attack vector are buffer overflows, SQL injection, Authorization failures, etc... We also must note the 'depth' of the compromise. Are we a talking about a compromise of an Web Application, the server or the data center? With the current speed of the industry, unless the 'model' behind the Software Development Lifecycle promotes security, then there will always be multiple ways to create security vulnerabilities. Unfortunately it does not end with a good Secure Software Development Lifecycle (SSDL). For example Microsoft currently has a better SSDL than Oracle, but is still creating insecure applications, frameworks and operating systems that (for example) are not able to handle malicious code executed from within (namely Full Trust .Net code and Vista's UAC/LUA). Microsoft understands yesterday's security problems (buffer overflows, Sql injections, xss, crypto attacks,etc...) but doesn't understand (or wants to understand) tomorrow's security problems (securely execution of malicious code, authorization vulnerabilities, race-conditions, malicious developers, CLR attacks, etc...). So here we end up with the good-old Business case. When there is no short-term business case and strong client/government demand for a secure solution/product/operating system, the companies delivering applications will not do it voluntarily (even when they have a good understanding of security and have developers who understand secure coding practices) So coming back to AJAX.... I would say: Show me your development model, mindset, motivation and past exploitation record; add in the technologies used, and I will show you where security vulnerabilities are very likely to exist. Dinis Cruz Owasp .Net Project www.owasp.net Jeff Williams wrote: Hi Eric, I think you've nailed what's really going on here. There's this huge timelag between when new technologies are introduced and when we (as a software development community) are really using them securely.As several folks have pointed out, there's nothing fundamentally new about the security issues created by AJAX. As a *security* community, our challenge is to translate the principles and practices that we understand to the new technologies that come along. Our track record isn't particularly good here by the way. We never translated the extensive access control work from the 80's to the web environment. We're starting to translate what we've learned about web apps to web services. But, realistically, it's going to be a while before we are effectively securing AJAX apps. OWASP, as an all volunteer open-source project, has a role to play here. When new technologies arise, we approach them from a bunch of different angles. Generally, the presentations at local chapters and email threads like this happen first. The Guide captures the issues more completely and fully. WebScarab adds support for the technology, and WebGoat lessons get built to help developers really learn. And maybe we even build some technology to help developers protect their applications. Look at the support we have for web services developers for an example. We've got several great presentations (and video podcasts), fantastic content in the Guide, excellent testing tools in WebScarab, and cool lessons in WebGoat. We've started doing similar stuff for AJAX as some others have mentioned. It's a huge challenge -- and we need all the help we can get. Please let me know if you have ideas about how we can be more effective. --Jeff Jeff Williams, Chair The OWASP Foundation http://www.owasp.org email: [EMAIL PROTECTED]-----Original Message----- From: [EMAIL PROTECTED] [mailto:owasp-dotnet- [EMAIL PROTECTED]] On Behalf Of Eric Swanson Sent: Tuesday, March 14, 2006 8:34 PM To: [EMAIL PROTECTED]; [email protected] Subject: RE: [Owasp-dotnet] Re: [SC-L] Is there any Security problem inAjax |
_______________________________________________ Secure Coding mailing list (SC-L) [email protected] List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
