This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Struts: Validator Turned Off"

From OWASP
Jump to: navigation, search
(Contents provided by Fortify.)
Line 2: Line 2:
 
{{Template:Fortify}}
 
{{Template:Fortify}}
  
==Abstract==
+
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 +
 
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 
 +
[[ASDR Table of Contents]]
 +
__TOC__
  
This action form mapping disables the form's validate() method.
 
  
 
==Description==
 
==Description==
 +
 +
This action form mapping disables the form's validate() method.
  
 
An action form mapping should never disable validation. Disabling validation disables the Struts Validator as well as any custom validation logic performed by the form.
 
An action form mapping should never disable validation. Disabling validation disables the Struts Validator as well as any custom validation logic performed by the form.
  
==Examples ==
+
 
 +
==Risk Factors==
 +
 
 +
TBD
 +
 
 +
==Examples==
  
 
An action form mapping that disables validation.
 
An action form mapping that disables validation.
Line 26: Line 39:
 
Disabling validation exposes this action to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.
 
Disabling validation exposes this action to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.
  
==Related Threats==
 
  
==Related Attacks==
 
  
==Related Vulnerabilities==
+
==Related [[Attacks]]==
 +
 
 +
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
==Related [[Controls]]==
 +
 
 +
* [[:Category:Input Validation]]
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
 
 +
TBD
  
==Related Countermeasures==
 
  
[[:Category:Input Validation]]
+
__NOTOC__
  
==Categories==
 
  
 +
[[Category:OWASP ASDR Project]]
 
[[Category:Input Validation Vulnerability]]
 
[[Category:Input Validation Vulnerability]]
 
[[Category:Struts]]
 
[[Category:Struts]]

Revision as of 00:17, 1 October 2008

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

This article includes content generously donated to OWASP by MicroFocus Logo.png

Last revision (mm/dd/yy): 10/1/2008

Vulnerabilities Table of Contents

ASDR Table of Contents


Description

This action form mapping disables the form's validate() method.

An action form mapping should never disable validation. Disabling validation disables the Struts Validator as well as any custom validation logic performed by the form.


Risk Factors

TBD

Examples

An action form mapping that disables validation.

	<action path="/download"
		type="com.website.d2.action.DownloadAction"
		name="downloadForm"
		scope="request"
		input=".download"
		validate="false">
	</action>

Disabling validation exposes this action to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.


Related Attacks


Related Vulnerabilities

Related Controls


Related Technical Impacts


References

TBD