Re: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax technology?
Gadi Evron wrote: > > In other words, it's just Javascript. Do your coding securely. I don't > like the big buzz. This is nothing new. Hola Gadi! *grin* I absolutely agree. It is absolutely not new . . . >>> The challenge is in helping people to understand what a security >>> boundary is. The problem is: We /*still*/ have _this_ problem . . . :} It's been my experience over the years that very, very, very few system architects understand the concept and design systems appropriately. Having said that, I'm not shaking my finger at them. If it were important to $MANAGEMENT that the system design be aware of it and respect it, it would be so. After all, in the end, this is all about risk management. /*That*/ is management's job. Apologies, but I have to get it off my chest every now and then . . . ;> > I wish I had a good Yoda quote right now, but all I can come up with is > Terry Goodkind, which I feel very ashamed of. NP. Thanks for turning me onto a new author! :) Cheers, /g ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax technology?
George Capehart wrote: Yvan Boily wrote: Hi George, I think a much more eloquent form of what you are saying is that validation must be performed each time data crosses a security boundary. Hello Yvan, I absolutely agree. Wish I'd said it myself . . . :) In other words, it's just Javascript. Do your coding securely. I don't like the big buzz. This is nothing new. The challenge is in helping people to understand what a security boundary is. Errrmm. Into understatement these days, eh? :) I wish I had a good Yoda quote right now, but all I can come up with is Terry Goodkind, which I feel very ashamed of. Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax technology?
Yvan Boily wrote: > Hi George, > > I think a much more eloquent form of what you are saying is that > validation must be performed each time data crosses a security > boundary. Hello Yvan, I absolutely agree. Wish I'd said it myself . . . :) > > The challenge is in helping people to understand what a security boundary is. Errrmm. Into understatement these days, eh? :) Thanks for your comments. Best regards, /g ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in Ajax technology?
Yes! :) I am speaking at the OWASP EU conference in Belgium (I hope people speak English 'cos my French is now quite appalling) at the end of May, and I have a paper submission for O'Reilly's OSCON in early July. I am still mulling over whether to submit a proposal to BlackHat as although I love junkets, I can't do too many - I have to work as well :) Next, once the chapter is released, it will be a major new addition to the OWASP Guide 2.1, and I'm sure we'll be doing something about promoting it at that point. There's not really any technology required to secure Ajax; it's all about the architecturally correct location of authorization, validation and preventing injection attacks. There's no magic technical bullet, WAF, or similar which can help fix these things. The issues with Ajax aren't really new, it's just that devs are introducing new classes of vulnerability because they have forgotten the hard lessons learnt in the past. thanks, Andrew On 15/03/2006, at 12:33 PM, Eric Swanson wrote: My question: How does OWASP plan to educate the public regarding security concerns raised by AJAX and, indeed, any new methodology or technology and what is its plan to develop tools that translate this education into practice? *AJAX and related methodologies should be addressed by all groups within OWASP, so I'm guessing that the .NET group isn't the only group actively discussing it. (AFLAX - a Flash version also raises the same concerns.) smime.p7s Description: S/MIME cryptographic signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Is there any Security problem in Ajax technology?
George Capehart wrote: Dinis Cruz wrote: I personally think that AJAX has the potential to create very insecure applications because it pushes the data validation and authorization layers back to the client (i.e. the browser) "AJAX brings 'Back the Rich Client' and all its security problems" Kentaro, on your AJAX application you must follow the rule-of-thumb of not trusting any data supplied by your own Client-Side-AJAX functions, and authorize every request. In a nutshell: any data validation and authorization decisions/actions made at the Client-Side-AJAX functions are only there for usability, and have NO security value. I enthusiastically agree with the above. I'll take it further and suggest that, even then, the input from the Web should/must be examined and sanitized before use . . . /*still*/ need to check for SQL injection attacks, etc. IMNSHO, identification, authorization and validation should always be done by the part of the system that is at risk if the input is bad (in any of the connotations of bad) . . . Indeed, but I believe the main point he was trying to make was: >>In a nutshell: any data validation and authorization decisions/actions made at the Client-Side-AJAX functions are only there for usability, and have NO security value. Much like with regular Java. Nothing changed. The issue is to think like an attacker. Any client-side defense can be thrown aside, discarded. Client-side defenses however are often very useful for "usability", i.e., so that the user is not allowed to send in bad Characters, or he/she wouldn't know their request was stopped server-side. Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
Re: [SC-L] Is there any Security problem in Ajax technology?
Dinis Cruz wrote: > I personally think that AJAX has the potential to create very insecure > applications because it pushes the data validation and authorization layers > back to the client (i.e. the browser) > > "AJAX brings 'Back the Rich Client' and all its security problems" > > Kentaro, on your AJAX application you must follow the rule-of-thumb of not > trusting any data supplied by your own Client-Side-AJAX functions, and > authorize every request. > > In a nutshell: any data validation and authorization decisions/actions made > at the Client-Side-AJAX functions are only there for usability, and have NO > security value. I enthusiastically agree with the above. I'll take it further and suggest that, even then, the input from the Web should/must be examined and sanitized before use . . . /*still*/ need to check for SQL injection attacks, etc. IMNSHO, identification, authorization and validation should always be done by the part of the system that is at risk if the input is bad (in any of the connotations of bad) . . . Cheers, /g ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
re: [SC-L] Is there any Security problem in Ajax technology?
I personally think that AJAX has the potential to create very insecure applications because it pushes the data validation and authorization layers back to the client (i.e. the browser)"AJAX brings 'Back the Rich Client' and all its security problems"Kentaro, on your AJAX application you must follow the rule-of-thumb of not trusting any data supplied by your own Client-Side-AJAX functions, and authorize every request.In a nutshell: any data validation and authorization decisions/actions made at the Client-Side-AJAX functions are only there for usability, and have NO security value.Hope this helpsDinis CruzOwasp .Net Projectwww.owasp.netFrom: "Kentaro Arai" <[EMAIL PROTECTED]>Sent: Monday, March 06, 2006 9:49 AMTo: "Secure Coding Mailing List" Subject: [SC-L] Is there any Security problem in Ajax technology?Hi, AllI'm designing a web application with Ajax technology and .NETFramework1.1.Do I need to consider any security problem, using the Ajax technology?Kentaro Arai___Secure Coding mailing list (SC-L)SC-L@securecoding.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - http://www.securecoding.org/list/charter.php ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
[SC-L] Is there any Security problem in Ajax technology?
Hi, All I'm designing a web application with Ajax technology and .NET Framework1.1. Do I need to consider any security problem, using the Ajax technology? Kentaro Arai ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
