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
