Minimize attack surface area - Revision history

KirstenS at 22:20, 7 April 2009

2009-04-07T22:20:04Z

2008-09-07T12:42:22Z

‎References

2008-09-07T12:41:57Z

2008-09-05T18:58:20Z

2006-06-14T14:48:41Z

2006-06-14T14:48:29Z

2006-06-14T14:48:03Z

2006-06-14T14:47:30Z

New page

{{Template:Principle}}

{{Template:Stub}}

==Categories==

[[Category:Principle]]

← Older revision		Revision as of 12:42, 7 September 2008
Line 44:		Line 44:


−	~~When the article is reviewed, the "Honeycomb" category SHOULD be removed and replaced with the "ASDR" category~~
−	~~<nowiki>[[Category:OWASP Honeycomb Project]]</nowiki>~~
−	~~<nowiki>[[Category:OWASP ASDR Project]]</nowiki>~~

	__NOTOC__		__NOTOC__

@@ Line 2: / Line 2: @@
 {{Template:Stub}}
 <br>
@@ Line 8: / Line 10: @@
-==Overview==
+==Description==
 Every feature that is added to an application adds a certain amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface area.
 For example, a web application implements online help with a search function. The search function may be vulnerable to SQL injection attacks. If the help feature was limited to authorized users, the attack likelihood is reduced. If the help feature’s search function was gated through centralized data validation routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was re-written to eliminate the search function (through better user interface, for example), this almost eliminates the attack surface area, even if the help feature was available to the Internet at large.
 [[Category:Principle]]

← Older revision		Revision as of 14:48, 14 June 2006
Line 8:		Line 8:

	For example, a web application implements online help with a search function. The search function may be vulnerable to SQL injection attacks. If the help feature was limited to authorized users, the attack likelihood is reduced. If the help feature’s search function was gated through centralized data validation routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was re-written to eliminate the search function (through better user interface, for example), this almost eliminates the attack surface area, even if the help feature was available to the Internet at large.		For example, a web application implements online help with a search function. The search function may be vulnerable to SQL injection attacks. If the help feature was limited to authorized users, the attack likelihood is reduced. If the help feature’s search function was gated through centralized data validation routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was re-written to eliminate the search function (through better user interface, for example), this almost eliminates the attack surface area, even if the help feature was available to the Internet at large.
−
−	~~==Categories==~~

	[[Category:Principle]]		[[Category:Principle]]