diff --git a/skf/markdown/knowledge_base/100-knowledge_base--Log_viewing_software_code_injection--.md b/skf/markdown/knowledge_base/100-knowledge_base--Log_viewing_software_code_injection--.md index b74f343de..c29901abc 100755 --- a/skf/markdown/knowledge_base/100-knowledge_base--Log_viewing_software_code_injection--.md +++ b/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. diff --git a/skf/markdown/knowledge_base/109-knowledge_base--Privilege_escalation--.md b/skf/markdown/knowledge_base/109-knowledge_base--Privilege_escalation--.md index 5e7ddb06f..760c842ad 100755 --- a/skf/markdown/knowledge_base/109-knowledge_base--Privilege_escalation--.md +++ b/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. diff --git a/skf/markdown/knowledge_base/11-knowledge_base--LDAP_injection--.md b/skf/markdown/knowledge_base/11-knowledge_base--LDAP_injection--.md index e88bef326..c80ed1840 100755 --- a/skf/markdown/knowledge_base/11-knowledge_base--LDAP_injection--.md +++ b/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. diff --git a/skf/markdown/knowledge_base/110-knowledge_base--Enforce_sequential_step_order--.md b/skf/markdown/knowledge_base/110-knowledge_base--Enforce_sequential_step_order--.md index c32c1e445..a779d4ea0 100755 --- a/skf/markdown/knowledge_base/110-knowledge_base--Enforce_sequential_step_order--.md +++ b/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