Merge pull request #1 from lukasz-a-krol/main

fixing typos, adding more relative links

content/learning-path/1/module-5.en.md

@@ -49,7 +49,7 @@ Read the resources and documents below to familiarize yourself a bit with (or re
   - Learn about DomainKeys Identified Mail (DKIM) and how, as an authentication standard, it is used to prevent email spoofing.
     - [https://docs.sendgrid.com/ui/account-and-settings/dkim-records](https://docs.sendgrid.com/ui/account-and-settings/dkim-records)
     - Use [https://mxtoolbox.com/dkim.aspx](https://mxtoolbox.com/dkim.aspx) to conduct a lookup on a DKIM authenticated domain. You can look up the records for your own organization, for example, by checking its main domain.
-- **(Advanced) **Familiarize yourself with various techniques and mechanisms spam filters use to identify spam / spoofed emails.
+- **(Advanced)** Familiarize yourself with various techniques and mechanisms spam filters use to identify spam / spoofed emails.
   - Look at the list of available modules (and selectors) supported by RSPAMD [https://rspamd.com/doc/modules/](https://rspamd.com/doc/modules/)
 
 ## Main Section

content/learning-path/1/module-5.fr.md

@@ -51,7 +51,7 @@ Lisez les ressources et documents ci-dessous pour vous familiariser avec (ou ré
   - Découvrez DomainKeys Identified Mail (DKIM) et comment, en tant que norme d'authentification, elle est utilisée pour empêcher l'usurpation d'adresses e-mail.
     - [https://docs.sendgrid.com/ui/account-and-settings/dkim-records](https://docs.sendgrid.com/ui/account-and-settings/dkim-records)
     - Utilisez [https://mxtoolbox.com/dkim.aspx](https://mxtoolbox.com/dkim.aspx) pour effectuer une recherche sur un domaine authentifié DKIM. Vous pouvez rechercher les enregistrements de votre propre organisation, par exemple, en vérifiant son domaine principal.
-- **(Avancé) **Familiarisez-vous avec les diverses techniques et mécanismes que les filtres antispam utilisent pour repérer les courriers indésirables et les adresses e-mail falsifiées.
+- **(Avancé)** Familiarisez-vous avec les diverses techniques et mécanismes que les filtres antispam utilisent pour repérer les courriers indésirables et les adresses e-mail falsifiées.
   - Consultez la liste des modules disponibles (et des sélecteurs) pris en charge par RSPAMD [https://rspamd.com/doc/modules/](https://rspamd.com/doc/modules/)
 
 ## Section Principale

content/learning-path/3/introduction.fr.md

@@ -34,7 +34,7 @@ Compromission de l'appareil et exfiltration des données via des logiciels malve
 Ce parcours d'apprentissage est avancé. Avant de l'entreprendre, les apprenants doivent :
 
 - Terminer le parcours d'apprentissage sur la _Détection des logiciels malveillants_, qui présente les principes fondamentaux des logiciels malveillants. En règle générale, vous utiliserez uniquement les informations que vous apprendrez ci-dessous pour effectuer une analyse plus approfondie des logiciels malveillants suspects qui n'ont pas été détectés à l'aide d'IoC existants, de sorte que ce parcours d'apprentissage peut être considéré comme une continuation de la détection des logiciels malveillants.
-- Terminer le parcours d'apprentissage [_Détection, enquête et suivi des infrastructures malveillantes_](https://docs.google.com/document/d/13if8JvR_TsGxja0Il48NBM-S1LKs29w_R_3LxxiLxS4/edit), qui enseigne les bases du DNS, du courrier électronique et du HTTP dont vous aurez besoin pour comprendre le comportement des logiciels malveillants.
+- Terminer le parcours d'apprentissage [_Détection, enquête et suivi des infrastructures malveillantes_](/fr/learning-path/1/), qui enseigne les bases du DNS, du courrier électronique et du HTTP dont vous aurez besoin pour comprendre le comportement des logiciels malveillants.
 - En fonction de la plateforme et des logiciels malveillants que vous analysez, vous aurez probablement besoin de connaissances en programmation et en système d'exploitation. En plus des compétences de base en ligne de commande, vous devrez avoir certaines connaissances concernant les langages de programmation et les architectures de sécurité utilisées par les principaux systèmes d'exploitation. Les exemples peuvent inclure C/C++ et l'assemblage x86 pour Windows, Java ou Kotlin pour Android, etc.
 - (facultatif) Selon le logiciel malveillant, vous devrez peut-être également pouvoir lire des langages de script tels que Perl, PowerShell, bash, etc. Les sections pour chaque plateforme devraient inclure des liens vers certaines ressources de soutien, mais vous devrez peut-être effectuer des recherches et des examens en dehors du cadre du parcours d'apprentissage selon ce que vous analysez.
 

content/learning-path/3/module-5.en.md

@@ -86,7 +86,7 @@ At this point, you should know how you acquired the malware, what it does, and h
 
 Attributing malware to a particular threat actor is a popular activity among malware analysts. However, it is difficult to get accurate results. Don’t feel as if you need to perform attribution if you’re not sure, the most important thing is publishing IoCs.
 
-In the Detecting, Investigating and Tracking Malicious Infrastructure learning path, we’ve also[ created a section on write-ups and reports](https://docs.google.com/document/d/1Qhka7uQYCBye-EQRQrrETo-ptik2yDAGDZg5DrncYF4/edit) that could be of help.
+In the Detecting, Investigating and Tracking Malicious Infrastructure learning path, we’ve also[ created a section on write-ups and reports](/en/learning-path/1/module-8/) that could be of help.
 
 The following public blog posts might give you some inspiration for your own reports. All of them use different tones and formats but all also contain IoCs.
 

content/learning-path/3/module-5.fr.md

@@ -87,7 +87,7 @@ Lorsque vous envisagez de créer des IoC, vous devez considérer ce qui est intr
 
 L'attribution de logiciels malveillants à un acteur de menace particulier est une activité populaire parmi les analystes de logiciels malveillants. Cependant, il est difficile d'obtenir des résultats précis. Ne vous obligez pas à effectuer l'attribution si vous avez des doutes, la chose la plus importante est la publication des IoC.
 
-Dans le parcours d'apprentissage Détection, enquête et suivi des infrastructures malveillantes, nous avons également [créé une section sur les articles et les rapports](https://docs.google.com/document/d/1Qhka7uQYCBye-EQRQrrETo-ptik2yDAGDZg5DrncYF4/edit) qui pourraient être utiles.
+Dans le parcours d'apprentissage Détection, enquête et suivi des infrastructures malveillantes, nous avons également [créé une section sur les articles et les rapports](/fr/learning-path/1/module-8/) qui pourraient être utiles.
 
 Les articles de blog publics suivants pourraient vous inspirer pour vos propres rapports. Tous utilisent des tons et des formats différents, mais tous contiennent également des IoC.
 

content/learning-path/4/module-2.en.md

@@ -110,7 +110,7 @@ which would display like this
 
 Output encoding is dependent on the context that the data will be used in. For HTML, you would encode HTML entities in the data. For data that was going to be included into a block of JavaScript, a different encoding would be used. If user data was going to be used in a database query yet another type of encoding would be used. Web frameworks and libraries should have functions to perform output encoding for you; it’s better to use those (hopefully) mature functions than to try to write them yourself from first principles.
 
-For a bit more on XSS, see [the OWASP guide on XSS](https://owasp.org/www-community/attacks/xss/). For an in-depth exploration, see the [Web Application Security Assessment learning path](https://docs.google.com/document/d/19v34droskAFgkp_qqcwiQLpc1hI1W-FjzHNV2QRBsaA/edit?usp=sharing).
+For a bit more on XSS, see [the OWASP guide on XSS](https://owasp.org/www-community/attacks/xss/). For an in-depth exploration, see the [Web Application Security Assessment learning path](/en/learning-path/5/).
 
 ### SQL injection (SQLi)
 
@@ -159,7 +159,7 @@ Unlike with XSS, output encoding is not a reliable way to prevent SQL injection.
 
 Instead, we can use a feature of every database engine that skips some of the initial parsing of the query entirely. This type of query is called a parameterized query, and using it is frequently called parameter binding. Instead of sending the database a string of text that contains both the structure of the query and the user’s data, we send one string that contains the structure of the query with placeholders in it for the data. Along with that string, we send the data for each placeholder. In this way, the user’s data is never parsed in a SQL context; no matter what they send, it will be treated exclusively as data. Not only does this protect against SQL injection, it makes the database queries slightly faster.
 
-For a bit more on SQL injection, see [the OWASP guide on it](https://owasp.org/www-community/attacks/SQL_Injection). For an in-depth exploration, see the [Web Application Security Assessment learning path](https://docs.google.com/document/d/19v34droskAFgkp_qqcwiQLpc1hI1W-FjzHNV2QRBsaA/edit?usp=sharing).
+For a bit more on SQL injection, see [the OWASP guide on it](https://owasp.org/www-community/attacks/SQL_Injection). For an in-depth exploration, see the [Web Application Security Assessment learning path](/en/learning-path/5/).
 
 ### Path injection/directory traversal/local file inclusion
 
@@ -244,7 +244,7 @@ To a large extent, the best advice for preventing this sort of attack is “don
 
 If this isn’t feasible, the site should only use and accept a very limited set of characters (such as letters and numbers) for user-specified filename components. This will still likely allow users to read or write arbitrary files within a specified directory, so the application developers must ensure that files in that directory aren’t executable by the web server, and that there is no sensitive data or important configuration information in that directory.
 
-For a bit more on path injection, see [the OWASP guide on it](https://owasp.org/www-community/attacks/Path_Traversal). For an in-depth exploration, see the [Web Application Security Assessment learning path](https://docs.google.com/document/d/19v34droskAFgkp_qqcwiQLpc1hI1W-FjzHNV2QRBsaA/edit?usp=sharing).
+For a bit more on path injection, see [the OWASP guide on it](https://owasp.org/www-community/attacks/Path_Traversal). For an in-depth exploration, see the [Web Application Security Assessment learning path](/en/learning-path/5/).
 
 ### Shell injection/command injection
 
@@ -344,7 +344,7 @@ Log into your DVWA and make sure the security level is set to low. Navigate to t
 
 As with path injection, the best way to prevent shell injection is “don’t do that.” Unlike with path injection, the advice to not run shell commands from the web server should not be given full consideration. The other alternatives (such as input data validation) are difficult to implement correctly, and may be impossible if the application needs to allow any sort of non-trivial input.
 
-For a bit more on shell injection, see [the OWASP guide on it](https://owasp.org/www-community/attacks/Command_Injection) and the [OWASP guide on preventing it](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html). For an in-depth exploration, see the [Web Application Security Assessment learning path](https://docs.google.com/document/d/19v34droskAFgkp_qqcwiQLpc1hI1W-FjzHNV2QRBsaA/edit?usp=sharing).
+For a bit more on shell injection, see [the OWASP guide on it](https://owasp.org/www-community/attacks/Command_Injection) and the [OWASP guide on preventing it](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html). For an in-depth exploration, see the [Web Application Security Assessment learning path](/en/learning-path/5/).
 
 ## Skill Check
 

content/learning-path/4/module-3.en.md

@@ -62,7 +62,7 @@ Reset links may also be sent via SMS. SMS is less likely to be intercepted than
 
 An alternate method of performing password resets involves asking the user questions that both the website and user know the answers to, but that an attacker might not. These tend to be extremely weak, or extremely strong methods of verifying the user’s identity. Standard “secret questions” like asking where the user was born, their mother’s maiden name, the make of their first car, etc. are quite weak. First off, an attacker may be able to easily find the answer to those questions. Secondly, most of them are impossible to change, so in the event that an attacker does discover an answer (even by compromising another website), they will be able to use them again and again. Lastly, most of these questions only have a handful of common answers. For example, if you ask a Korean person their mother’s maiden name, a significant proportion of the answers will be “Kim” or “Lee”. The other, more secure type of secret question involves offline communications between the website and the user. Examples of this are things like utility bills and bank statements. For the user to reset their password, they would enter, for instance, the amounts of 3rd and 5th transactions in their bank statement. The user would only be allowed a few tries, and then would need to perform an even less convenient reset process with customer service. This reset process can be very secure, though in the days of online statements, it’s probably less secure than emailing a token.
 
-For a bit more on secure password reset, see [the OWASP cheat sheet on Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html). For an in-depth exploration of authentication and authorization vulnerabilities, see the [Web Application Security Assessment learning path](https://docs.google.com/document/d/19v34droskAFgkp_qqcwiQLpc1hI1W-FjzHNV2QRBsaA/edit?usp=sharing).
+For a bit more on secure password reset, see [the OWASP cheat sheet on Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html). For an in-depth exploration of authentication and authorization vulnerabilities, see the [Web Application Security Assessment learning path](/en/learning-path/5/).
 
 ### Credential strength