Validation performed in client

From OWASP
Revision as of 08:23, 12 June 2006 by Jeff Williams (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.


Overview

Performing validation in client side code, generally JavaScript, provides no protection for server-side code. An attacker can simply disable JavaScript, use telnet, or use a security testing proxy such as WebScarab to bypass the client side validation.

Consequences

  • Unvalidated input corrupts business logic (XSS, injection, etc...)

Exposure period

  • Design phase

Platform

  • Languages: any
  • Operating platforms: any

Required resources

  • None

Severity

Very high -- allows malicious input to be used in business logic.

Likelihood of exploit

Very likely

Avoidance and mitigation

Validation must be performed in the business layer.

Discussion

Client-side validation is widely used, but is not security relevant. The only advantage of client-side validation, from a security perspective, is that intrusion detection may be more effective. Because only pre-validated input should arrive at an application (assuming JavaScript is enabled), it can be assumed that any bad input represents an attack. The application can respond much more harshly if it knows that it is under attack. Some responses might be session invalidation, logging, or notification to an administrator.

Examples

TBD

Related problems

TBD