T.Gigler: doppeltes '|language=de' gelöscht

2017-04-23T20:00:39Z

doppeltes '|language=de' gelöscht

T.Gigler: Top_10_2010:SummaryTableHeaderBeginTemplate|type=images => mit Bildern

2013-06-15T22:29:48Z

Top_10_2010:SummaryTableHeaderBeginTemplate|type=images => mit Bildern

T.Gigler: Import vom engl. Wiki, mit language=de

2013-06-15T18:20:34Z

Import vom engl. Wiki, mit language=de

New page

{{Top_10_2013:TopTemplate
|usenext=2013NextLink
|next=A8-{{Top_10_2010:ByTheNumbers
|8
|year=2013
|language=de}}
|useprev=2013PrevLink
|prev=A6-{{Top_10_2010:ByTheNumbers
|6
|year=2013
|language=de}}
|year=2013
|language=de
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2013|language=de}}
{{Top_10:SummaryTableTemplate|exploitability=1|prevalence=2|detectability=2|impact=2|language=de|year=2013|language=de}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013}}
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Anyone with network access can send your application a request. Could anonymous users access private functionality or regular users a privileged function?
</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Attacker, who is an authorized system user, simply changes the URL or a parameter to a privileged function. Is access granted? Anonymous users could access private functions that aren’t protected.

</td>
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.

Detecting such flaws is easy. The hardest part is identifying which pages (URLs) or functions exist to attack.

</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Such flaws allow attackers to access unauthorized functionality. Administrative functions are key targets for this type of attack.

</td>
<td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>
Cbusiness value of the exposed functions and the data they process.

Also consider the impact to your reputation if this vulnerability became onsider the public.

</td>
{{Top_10_2010:SummaryTableEndTemplate}}

{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=vulnerableTo|position=firstLeft|risk=7|year=2013|language=de}}
The best way to find out if an application has failed to properly restrict function level access is to verify every application function:
# Does the UI show navigation to unauthorized functions?
# Are server side authentication or authorization checks missing?
# Are server side checks done that solely rely on information provided by the attacker?

Using a proxy, browse your application with a privileged role. Then revisit restricted pages using a less privileged role. If the server responses are alike, you're probably vulnerable. Some testing proxies directly support this type of analysis.

You can also check the access control implementation in the code. Try following a single privileged request through the code and verifying the authorization pattern. Then search the codebase to find where that pattern is not being followed.

Automated tools are unlikely to find these problems.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=7|year=2013|language=de}}
Your application should have a consistent and easy to analyze authorization module that is invoked from all of your business functions. Frequently, such protection is provided by one or more components external to the application code.
# Think about the process for managing entitlements and ensure you can update and audit easily. Don’t hard code.
# The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.
# If the function is involved in a workflow, check to make sure the conditions are in the proper state to allow access.

NOTE: Most web applications don’t display links and buttons to unauthorized functions, but this “presentation layer access control” doesn’t actually provide protection. You must also implement checks in the controller or business logic.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=left|risk=7|year=2013|language=de}}
'''Scenario #1:''' The attacker simply force browses to target URLs. The following URLs require authentication. Admin rights are also required for access to the admin_getappInfo page.

{{Top_10_2010:ExampleBeginTemplate|year=2013}}<nowiki>
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
</nowiki> {{Top_10_2010:ExampleEndTemplate}}
If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-admin, user is allowed to access the admin_getappInfo page, this is also a flaw, and may lead the attacker to more improperly protected admin pages.

'''Scenario #2:''' A page provides an 'action' parameter to specify the function being invoked, and different actions require different roles. If these roles aren’t enforced, that’s a flaw.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|risk=7|year=2013|language=de}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate}}
* [https://www.owasp.org/index.php/Top_10_2007-Failure_to_Restrict_URL_Access OWASP Top 10-2007 on Failure to Restrict URL Access]
* [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessController.html ESAPI Access Control API]
* [https://www.owasp.org/index.php/Guide_to_Authorization OWASP Development Guide: Chapter on Authorization]
* [https://www.owasp.org/index.php/Testing_for_Path_Traversal OWASP Testing Guide: Testing for Path Traversal]
* [https://www.owasp.org/index.php/Forced_browsing OWASP Article on Forced Browsing]

For additional access control requirements, see the [https://www.owasp.org/index.php/ASVS ASVS requirements area for Access Control (V4)].

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|language=de}}
* [http://cwe.mitre.org/data/definitions/285.html CWE Entry 285 on Improper Access Control (Authorization)]

{{Top_10_2013:BottomAdvancedTemplate
|type={{Top_10_2010:StyleTemplate}}
|usenext=2013NextLink
|next=A8-{{Top_10_2010:ByTheNumbers
|8
|year=2013
|language=de}}
|useprev=2013PrevLink
|prev=A6-{{Top_10_2010:ByTheNumbers
|6
|year=2013
|language=de}}
|year=2013
|language=de
}}

@@ Line 15: / Line 15: @@
 {{Top_10_2010:SummaryTableHeaderBeginTemplate|type=images|year=2013|language=de}}
-  {{Top_10:SummaryTableTemplate|exploitability=1|prevalence=2|detectability=2|impact=2|language=de|year=2013|language=de}}
+  {{Top_10:SummaryTableTemplate|exploitability=1|prevalence=2|detectability=2|impact=2|year=2013|language=de}}
 {{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013}}
       <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>

Germany/Projekte/Top 10-2013-A7-Fehlerhafte Autorisierung auf Anwendungsebene - Revision history

T.Gigler: doppeltes '|language=de' gelöscht

T.Gigler: Top_10_2010:SummaryTableHeaderBeginTemplate|type=images => mit Bildern

T.Gigler: Import vom engl. Wiki, mit language=de