[Esapi-user] [Esapi-dev] Why ESAPI crypto uses a custom serialization scheme

Jim Manico jim.manico at owasp.org
Sat May 1 11:56:30 EDT 2010


But Kevin - once your client is compromised - it's game over anyway.  
CSRF protections are moot, keylogger steals your pass, etc. What's  
makes JS crypto so special as a "bad" practice?

Jim Manico

On May 1, 2010, at 8:51 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com>  
wrote:

> Jim Manico wrote:
>> This is not even a security issue in my mind. It's just getting  
>> chit to
>> work.
>>
>> Requirements:
>>
>> 1) web 3.0 style client ( pure js )
>> 2) no plug in dependencies
>> 3) webservice(s) require signed request body
>>
>> I do not trust client side controls for obvious reasons. But the
>> scenario above is becomming very common for enterprises and other
>> organizations who use the latest web technologies.
>
> As long as those organizations understand that they are operating
> with the assumption that the client end is completely trusted, then
> that is OK. However, I frankly don't think that most of them have
> probably thought it through. The may trust the _human user_ sitting
> behind a client browser, but trusting the client end completely
> requires a much deeper analysis than that because of all the client- 
> side
> malware issues. (I guess that's part of your job, to explain it to
> them, right? :)
>
> -kevin
> -- 
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts  
> agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of  
> MIME


More information about the Esapi-user mailing list