TaintedPermissionsCheck.qhelp

<!DOCTYPE qhelp PUBLIC
  "-//Semmle//qhelp//EN"
  "qhelp.dtd">
<qhelp>
<overview>
<p>Using user-controlled data in a permissions check may allow a user 
to gain unauthorized access to protected functionality or data.</p>

</overview>
<recommendation>

<p>When checking whether a user is authorized for a particular activity, 
do not use data that is controlled by that user in the permissions check. 
If necessary, always validate the input, ideally against a fixed
list of expected values.</p>

<p>Similarly, do not decide which permission to check for based on user data. 
In particular, avoid using computation to decide which permissions to check for.
Use fixed permissions for particular actions, rather than generating the 
permission to check for.</p>

</recommendation>
<example>

<p>This example, using the Apache Shiro security framework, shows two ways to specify the 
permissions to check. The first way uses a string, <code>whatDoTheyWantToDo</code>,
to specify the permissions to check. However, this string is built from user input. 
This can allow an attacker to force a check against a permission that they know they
have, rather than the permission that should be checked. For example, while trying
to access the account details of another user, the attacker could force the system to check
whether they had permissions to access their <i>own</i> account details, which is incorrect,
and would allow them to perform the action. The second, more secure way uses a fixed check that does
not depend on data that is controlled by the user.</p>

<sample src="TaintedPermissionsCheck.java" />

</example>
<references>

<li>The CERT Oracle Secure Coding Standard for Java:
  <a href="https://www.securecoding.cert.org/confluence/display/java/SEC02-J.+Do+not+base+security+checks+on+untrusted+sources">SEC02-J. Do not base security checks on untrusted sources</a>.</li>



<!--  LocalWords:  CWE
 -->

</references>
</qhelp>