Merge branch 'master' into RiieCco-patch-9

skf/markdown/knowledge_base/100-knowledge_base--Log_viewing_software_code_injection--.md

@@ -5,7 +5,8 @@ Whenever user supplied input is being handled into log viewing software, this so
 ## Solution:
 
 You should consider these three controls when supplying information to the log viewing software:
-•	Design: If at all possible, avoid logging data that came from external inputs.
-•	Implementation: Ensure that all log entries are statically created, or if they must record external data that the input is vigorously white-list checked.
-•	Run time: Avoid viewing logs with tools that may interpret control characters in the file, such as command-line shells.
+    •	Design: If at all possible, avoid logging data that came from external inputs.
+    •	Implementation: Ensure that all log entries are statically created, or if they must record external data that the input       is vigorously white-list checked.  
+    •	Run time: Avoid viewing logs with tools that may interpret control characters in the file, such as command-line shells.
+
 Also verify that all non-printable symbols and field separators are properly encoded in log entries, to prevent log injection.

skf/markdown/knowledge_base/109-knowledge_base--Privilege_escalation--.md

@@ -1,7 +1,13 @@
 ## Description:
 
-In every portion of the application where a user can create information in the database (e.g., making a payment, adding a contact, or sending a message), then he can receive information (statement of account, order details, etc.), or delete information (drop users, messages, etc.), it is necessary to record that functionality. The tester should try to access such functions as another user in order to verify if it is possible to access a function that should not be permitted by the users role/privilege (but might be permitted as another user).
+Attackers with low access rights wil always try to elevate their privileges in order to get more sensitive information/functionalities at their disposal. This can be achieved by for example:
+
+ - Functions that fail to check authorization
+ - Compromised functions/services that run with higher privileges
+ - Compromised user accounts with higher privileges
+
+These examples just scratch the surface of what attackers will try in order to elevate their privilages on your application/system. Therefore it is very important to take this reccomendation high into account.
 
 ## Solution:
 
-Checking if a user has enough authorization to execute certain request should always be enforced on the server-side. Also, you may apply the Principle of Least privilege, the principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions. For example, if a user only requires access to the network, read access to a database table, and the ability to write to a log, this describes all the permissions that should be granted. Under no circumstances should the user be granted administrative privileges. Also for making testing easier, you can create Unit-tests that verifies the user role permissions.
+Checking if a user has enough authorization to execute certain request should always be enforced on the server-side. Also, you may apply the Principle of Least privilege, the principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions. For example, if a user only requires access to the network, read access to a database table, and the ability to write to a log, this describes all the permissions that should be granted. Under no circumstances should the user be granted administrative privileges. 

skf/markdown/knowledge_base/11-knowledge_base--LDAP_injection--.md

@@ -4,4 +4,4 @@ LDAP (Lightweight Directory Access Protocol) Injection is an attack used to expl
 
 ## Solution:
 
-The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries does not contain any attacks. However, in some cases, it is necessary to include special characters in the input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually LDAP query.
+The best way to prevent LDAP injection is to use a positive validation scheme for ensuring that the data going into your queries does not contain any attacks. However, in some cases, it is necessary to include special characters in the input that is passed into an LDAP query. In this case, using escaping can prevent the LDAP interpreter from thinking those special characters are actually part of the LDAP query.

skf/markdown/knowledge_base/110-knowledge_base--Enforce_sequential_step_order--.md

@@ -12,7 +12,3 @@ the application to only process business logic flows in sequential step order, w
 steps being processed in realistic human time, and not process out of order, skipped steps,
 processed steps from another user, or too quickly submitted transactions.
 
-Recommended knowledge base items:
-
-- Aggregate user requests
-- CSRF injection

skf/markdown/knowledge_base/113-knowledge_base--Prevent_password_pre_filling--.md

@@ -20,7 +20,4 @@ compute, key derivation functions are ideally suited for password hashing use ca
 Examples of good ways to store passwords are with, BCRYPT, Blowfish or in some cases SCRYPT
 which is a little harder to implement correctly
 
-NOTE: Password pre-filling also happens when using the browsers password manager. For the login input
-fields the 'autocomplete=off' HTML attribute should be added to disable the password manager. The credentials
-could otherwise be stolen by XSS attacks whenever an attacker injects an HTML login form into the application
-which is pre-filled by the password manager.
+NOTE: Password pre-filling also happens when using the browsers password manager. However this process is different fromt he context described above since the description above implies an application that pre-filles credentials from the database/localstorage/etc.

skf/markdown/knowledge_base/122-knowledge_base--HTTPS_and_weakly_or_unencrypted_links--.md

@@ -8,6 +8,4 @@ vulnerable data towards other unencrypted/weak encrypted links in your applicati
 
 ## Solution:
 
-Verify that credentials are transported using a suitable encrypted link and that all pages/functions that
-require a user to enter credentials are done so using an encrypted link.
-
+Verify that credentials or other sensitive information is transported via TLS.