mirror of
https://github.com/github/codeql.git
synced 2026-01-29 22:32:58 +01:00
Fix missing </p> in qhelp.
This commit is contained in:
@@ -6,25 +6,26 @@ Testing untrusted user input against a fixed constant results in
|
||||
a bypass of the conditional check as the attacker may alter the input to match the constant.
|
||||
When an incorrect check of this type is used to guard a potentially sensitive block,
|
||||
it results an attacker gaining access to the sensitive block.
|
||||
</p>
|
||||
</p>
|
||||
</overview>
|
||||
<recommendation>
|
||||
<p>
|
||||
Never decide whether to authenticate a user based on data that may be controlled by that user.
|
||||
If necessary, ensure that the data is validated extensively when it is input before any
|
||||
authentication checks are performed.
|
||||
</p>
|
||||
<p>
|
||||
</p>
|
||||
<p>
|
||||
It is still possible to have a system that "remembers" users, thus not requiring
|
||||
the user to login on every interaction. For example, personalization settings can be applied
|
||||
without authentication because this is not sensitive information. However, users
|
||||
should be allowed to take sensitive actions only when they have been fully authenticated.
|
||||
should be allowed to take sensitive actions only when they have been fully authenticated.
|
||||
</p>
|
||||
</recommendation>
|
||||
<example>
|
||||
<p>
|
||||
The following example shows a comparison where an user controlled
|
||||
expression is used to guard a sensitive method. This should be avoided.:
|
||||
</p>
|
||||
</p>
|
||||
<sample src="SensitiveConditionBypassBad.go" />
|
||||
</example>
|
||||
</qhelp>
|
||||
|
||||
Reference in New Issue
Block a user