Re: [Owasp-dotnet] Re: Is there any Security problem in Ajax technology?

[dinis at ddplus.net (Dinis Cruz)]

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: jeff.williams at owasp.org
>
>
>   
> > -----Original Message-----
> > From: owasp-dotnet-admin at lists.sourceforge.net [mailto:owasp-dotnet-
> > admin at lists.sourceforge.net] On Behalf Of Eric Swanson
> > Sent: Tuesday, March 14, 2006 8:34 PM
> > To: owasp-dotnet at lists.sourceforge.net; SC-L at securecoding.org
> > Subject: RE: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in
> >     
> Ajax
>   
> > technology?
> >
> > 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.)
> >
> > The security concerns with the AJAX method are the same as they have
> >     
> always
>   
> > been and the standard checklists still apply.  I think the real concern is
> > that the popularity of AJAX will continue to enable ignorant programmers
> >     
> to
>   
> > develop insecure solutions and possibly more importantly solutions that
> > violate personal privacy (i.e. the AJAX concept allows a website to
> >     
> collect
>   
> > information as you type it, regardless of whether you explicitly submit
> >     
> the
>   
> > information -- this was possible using hidden frames in the past, but it
> > will become a more evident problem as popularity increases; I raised this
> > issue last year regarding auto-form completion programs).
> >
> > AJAX is just another method of making a request to the server and (yet
> > another redundant point) all requests need to be authorized and validated.
> > The same applies to EVERY request to the server.
> >
> > *The barrier for rapid, rich-client development is getting lower as
> > high-level programming progresses and implementation choices are
> > ever-growing.  It's up to groups like this to make security concerns
> >     
> evident
>   
> > to all parties, standardize security practices, provide the resources and
> > tools to educate and verify conformity to standards, etc.
> >
> > --Eric Swanson
> >
> > -----Original Message-----
> > From: owasp-dotnet-admin at lists.sourceforge.net
> > [mailto:owasp-dotnet-admin at lists.sourceforge.net] On Behalf Of Yvan Boily
> > Sent: Tuesday, March 14, 2006 9:35 AM
> > To: George Capehart
> > Cc: Dinis Cruz; SC-L at securecoding.org; owasp-dotnet at lists.sourceforge.net
> > Subject: Re: [Owasp-dotnet] Re: [SC-L] Is there any Security problem in
> >     
> Ajax
>   
> > technology?
> >
> > 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.
> >
> > The challenge is in helping people to understand what a security boundary
> > is.
> >
> > Regards,
> > Yvan Boily
> >
> > On 3/13/06, George Capehart <gwc at acm.org> 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) . . .
> > >
> > > Cheers,
> > >
> > > /g
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > >       
> > language
> >     
> > > that extends applications into web and mobile media. Attend the live
> > >       
> > webcast
> >     
> > > and join the prime developer group breaking into this new coding
> > >       
> > territory!
> >     
> > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
> > > _______________________________________________
> > > Owasp-dotnet mailing list
> > > Owasp-dotnet at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
> > >
> > >       
> > --
> > ____
> > ygjb
> > Computer Science is no more about computers than astronomy is about
> > telescopes. E. W. Dijkstra
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> >     
> language
>   
> > that extends applications into web and mobile media. Attend the live
> >     
> webcast
>   
> > and join the prime developer group breaking into this new coding
> >     
> territory!
>   
> > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> > _______________________________________________
> > Owasp-dotnet mailing list
> > Owasp-dotnet at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> >     
> language
>   
> > that extends applications into web and mobile media. Attend the live
> >     
> webcast
>   
> > and join the prime developer group breaking into this new coding
> >     
> territory!
>   
> > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> > _______________________________________________
> > Owasp-dotnet mailing list
> > Owasp-dotnet at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
> >     
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Owasp-dotnet mailing list
> Owasp-dotnet at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-dotnet
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20060328/5a500233/attachment.html