add spanish security placeholder files

sections/security/avoid_publishing_secrets.spanish.md

@@ -0,0 +1,44 @@
+# Avoid publishing secrets to the npm registry
+
+### One Paragraph Explainer
+Precautions should be taken to avoid the risk of accidentally publishing secrets to public npm registries. An `.npmignore` file can be used to blacklist specific files or folders, or the `files` array in `package.json` can act as a whitelist.
+
+To gain a view of what npm publish will really publish to the registry, the `--dry-run` flag can be added the npm publish command to provide a verbose view of the tarbell package created.
+
+It is important to note that if a project is utilising both `.npmignore` and `.gitignore` files, everything which isn't in `.npmignore` is published to the registry(i.e. the `.npmignore` file overrides the `.gitignore`). This condition is a common source of confusion and is a problem that can lead to leaking secrets. Developers may end up updating the `.gitignore` file, but forget to update `.npmignore` as well, which can lead to a potentially sensitive file not being pushed to source control, but still being included in the npm package.
+
+### Code example
+Example .npmignore file
+```
+#tests
+test
+coverage
+
+#build tools
+.travis.yml
+.jenkins.yml
+
+#environment
+.env
+.config
+
+```
+
+Example use of files array in package.json
+
+```
+{ 
+  "files" : [
+    "dist/moment.js",
+    "dist/moment.min.js"
+  ]
+}
+```
+
+### What other bloggers say
+
+From the blog by [Liran Tal & Juan Picado at Snyk](https://snyk.io/blog/ten-npm-security-best-practices/):
+> ... Another good practice to adopt is making use of the files property in package.json, which works as a whitelist and specifies the array of files to be included in the package that is to be created and installed (while the ignore file functions as a blacklist). The files property and an ignore file can both be used together to determine which files should explicitly be included, as well as excluded, from the package. When using both, the former the files property in package.json takes precedence over the ignore file.
+
+From the [npm blog](https://blog.npmjs.org/post/165769683050/publishing-what-you-mean-to-publish)
+> ... When you run npm publish, npm bundles up all the files in the current directory. It makes a few decisions for you about what to include and what to ignore. To make these decisions, it uses the contents of several files in your project directory. These files include .gitignore, .npmignore, and the files array in the package.json. It also always includes certain files and ignores others.

sections/security/avoideval.spanish.md

@@ -0,0 +1,23 @@
+# Avoid JS eval statements
+
+### One Paragraph Explainer
+
+`eval()`, `setTimeout()`, `setInterval()`, and `new Function()` are global functions, often used in Node.js, which accept a string parameter representing a JavaScript expression, statement, or sequence of statements. The security concern of using these functions is the possibility that untrusted user input might find its way into code execution leading to server compromise, as evaluating user code essentially allows an attacker to perform any actions that you can. It is suggested to refactor code to not rely on the usage of these functions where user input could be passed to the function and executed.
+
+### Code example
+
+```javascript
+// example of malicious code which an attacker was able to input
+userInput = "require('child_process').spawn('rm', ['-rf', '/'])";
+
+// malicious code executed
+eval(userInput);
+```
+
+### What other bloggers say
+
+From the Essential Node.js Security book by [Liran Tal](https://leanpub.com/nodejssecurity):
+> The eval() function is perhaps of the most frowned upon JavaScript pieces from a security
+perspective. It parses a JavaScript string as text, and executes it as if it were a JavaScript code.
+Mixing that with untrusted user input that might find it’s way to eval() is a recipe for disaster that
+can end up with server compromise.

sections/security/bcryptpasswords.spanish.md

@@ -0,0 +1,30 @@
+# Avoid using the Node.js Crypto library for passwords, use Bcrypt
+
+### One Paragraph Explainer
+
+When storing user passwords, using an adaptive hashing algorithm such as bcrypt, offered by the [bcrypt npm module](https://www.npmjs.com/package/bcrypt) is recommended as opposed to using the native Node.js crypto module. `Math.random()` should also never be used as part of any password or token generation due to its predictability.
+
+The `bcrypt` module or similar should be used as opposed to the JavaScript implementation, as when using `bcrypt`, a number of 'rounds' can be specified in order to provide a secure hash. This sets the work factor or the number of 'rounds' the data is processed for, and more hashing rounds leads to more secure hash (although this at the cost of CPU time). The introduction of hashing rounds means that the brute force factor is significantly reduced, as password crackers are slowed down increasing the time required to generate one attempt.
+
+### Code example
+
+```javascript
+// asynchronously generate a secure password using 10 hashing rounds
+bcrypt.hash('myPassword', 10, function(err, hash) {
+  // Store secure hash in user record
+});
+
+// compare a provided password input with saved hash
+bcrypt.compare('somePassword', hash, function(err, match) {
+  if(match) {
+   // Passwords match
+  } else {
+   // Passwords don't match
+  } 
+});
+```
+
+### What other bloggers say
+
+From the blog by [Max McCarty](https://dzone.com/articles/nodejs-and-password-storage-with-bcrypt):
+> ... it’s not just using the right hashing algorithm. I’ve talked extensively about how the right tool also includes the necessary ingredient of “time” as part of the password hashing algorithm and what it means for the attacker who’s trying to crack passwords through brute-force.

sections/security/childprocesses.spanish.md

@@ -0,0 +1,31 @@
+# Be cautious when working with child processes
+
+### One Paragraph Explainer
+
+As great as child processes are, they should be used with caution. Passing in user input must be sanitized, if not avoided at all.
+The dangers of unsanitized input executing system-level logic are unlimited, reaching from remote code execution to the exposure of
+sensitive system data and even data loss. A check list of preparations could look like this
+
+- avoid user input in every case, otherwise validate and sanitize it
+- limit the privileges of the parent and child processes using user/group identities
+- run your process inside of an isolated environment to prevent unwanted side-effects if the other preparations fail
+
+### Code example: Dangers of unsanitized child process executions
+
+```javascript
+const { exec } = require('child_process');
+
+...
+
+// as an example, take a script that takes two arguments, one of them is unsanitized user input
+exec('"/path/to/test file/someScript.sh" --someOption ' + input);
+
+// -> imagine what could happen if the user simply enters something like '&& rm -rf --no-preserve-root /'
+// you'd be in for an unwanted surprise
+```
+
+### Additional resources
+
+From the Node.js child process [documentation](https://nodejs.org/dist/latest-v8.x/docs/api/child_process.html#child_process_child_process_exec_command_options_callback):
+
+> Never pass unsanitized user input to this function. Any input containing shell metacharacters may be used to trigger arbitrary command execution.

sections/security/commonsecuritybestpractices.spanish.md

@@ -0,0 +1,99 @@
+[✔]: ../../assets/images/checkbox-small-blue.png
+
+# Common Node.js security best practices
+
+The common security guidelines section contains best practices that are standardized in many frameworks and conventions, running an application with SSL/TLS, for example, should be a common guideline and convention followed in every setup to achieve great security benefits.
+
+## ![✔] Use SSL/TLS to encrypt the client-server connection
+
+**TL;DR:** In the times of [free SSL/TLS certificates](https://letsencrypt.org/) and easy configuration of those, you do no longer have to weigh advantages and disadvantages of using a secure server because the advantages such as security, support of modern technology and trust clearly outweigh the disadvantages like minimal overhead compared to pure HTTP.
+
+**Otherwise:** Attackers could perform man-in-the-middle attacks, spy on your users' behaviour and perform even more malicious actions when the connection is unencrypted
+
+🔗 [**Read More: Running a secure Node.js server**](/sections/security/secureserver.md)
+
+<br/><br/>
+
+## ![✔] Comparing secret values and hashes securely
+
+**TL;DR:** When comparing secret values or hashes like HMAC digests, you should use the [`crypto.timingSafeEqual(a, b)`](https://nodejs.org/dist/latest-v9.x/docs/api/crypto.html#crypto_crypto_timingsafeequal_a_b) function Node provides out of the box since Node.js v6.6.0. This method compares two given objects and keeps comparing even if data does not match. The default equality comparison methods would simply return after a character mismatch, allowing timing attacks based on the operation length.
+
+**Otherwise:** Using default equality comparison operators you might expose critical information based on the time taken to compare two objects
+
+<br/><br/>
+
+## ![✔] Generating random strings using Node.js
+
+**TL;DR:** Using a custom-built function generating pseudo-random strings for tokens and other security-sensitive use cases might actually not be as random as you think, rendering your application vulnerable to cryptographic attacks. When you have to generate secure random strings, use the [`crypto.RandomBytes(size, [callback])`](https://nodejs.org/dist/latest-v9.x/docs/api/crypto.html#crypto_crypto_randombytes_size_callback) function using available entropy provided by the system.
+
+**Otherwise:** When generating pseudo-random strings without cryptographically secure methods, attackers might predict and reproduce the generated results, rendering your application insecure
+
+<br/><br/>
+
+Going on, below we've listed some important bits of advice from the OWASP project.
+
+## ![✔] OWASP A2: Broken Authentication
+
+- Require MFA/2FA for important services and accounts
+- Rotate passwords and access keys frequently, including SSH keys
+- Apply strong password policies, both for ops and in-application user management ([🔗 OWASP password recommendation](https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls.22))
+- Do not ship or deploy your application with any default credentials, particularly for admin users or external services you depend on
+- Use only standard authentication methods like OAuth, OpenID, etc.  - **avoid** basic authentication
+- Auth rate limiting: Disallow more than _X_ login attempts (including password recovery, etc.) in a period of _Y_
+- On login failure, don't let the user know whether the username or password verification failed, just return a common auth error
+- Consider using a centralized user management system to avoid managing multiple accounts per employee (e.g. GitHub, AWS, Jenkins, etc) and to benefit from a battle-tested user management system
+
+## ![✔] OWASP A5:  Broken access control
+
+- Respect the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)  -  every component and DevOps person should only have access to the necessary information and resources
+- **Never** work with the console/root (full-privilege) account except for account management
+- Run all instances/containers on behalf of a role/service account
+- Assign permissions to groups and not to users. This should make permission management easier and more transparent for most cases
+
+## ![✔] OWASP A6: Security Misconfiguration
+
+- Access to production environment internals is done through the internal network only, use SSH or other ways, but _never_ expose internal services
+- Restrict internal network access  - explicitly set which resource can access other resources (e.g. network policy or subnets)
+- If using cookies, configure it to "secured" mode where it's being sent over SSL only
+- If using cookies, configure it for "same site" only so only requests from same domain will get back the designated cookies
+- If using cookies, prefer "HttpOnly" configuration that prevent client-side JavaScript code from accessing the cookies
+- Protect each VPC with strict and restrictive access rules
+- Prioritize threats using any standard security threat modeling like STRIDE or DREAD
+- Protect against DDoS attacks using HTTP(S) and TCP load balancers
+- Perform periodic penetration tests by specialized agencies
+
+## ![✔] OWASP A3: Sensitive Data Exposure
+
+- Only accept SSL/TLS connections, enforce Strict-Transport-Security using headers
+- Separate the network into segments (i.e. subnets) and ensure each node has the least necessary networking access permissions
+- Group all services/instances that need no internet access and explicitly disallow any outgoing connection (a.k.a private subnet)
+- Store all secrets in a vault products like AWS KMS, HashiCorp Vault or Google Cloud KMS
+- Lockdown sensitive instance metadata using metadata
+- Encrypt data in transit when it leaves a physical boundary
+- Don't include secrets in log statements
+- Avoid showing plain passwords in the frontend, take necessary measures in the backend and never store sensitive information in plaintext
+
+## ![✔] OWASP A9: Using Components With Known Security Vulneraibilities
+
+- Scan docker images for known vulnerabilities (using Docker's and other vendors offer scanning services)
+- Enable automatic instance (machine) patching and upgrades to avoid running old OS versions that lack security patches
+- Provide the user with both 'id', 'access' and 'refresh' token so the access token is short-lived and renewed with the refresh token
+- Log and audit each API call to cloud and management services (e.g who deleted the S3 bucket?) using services like AWS CloudTrail
+- Run the security checker of your cloud provider (e.g. AWS security trust advisor)
+
+
+## ![✔] OWASP A10: Insufficient Logging & Monitoring
+
+- Alert on remarkable or suspicious auditing events like user login, new user creation, permission change, etc
+- Alert on irregular amount of login failures (or equivelant actions like forgot password)
+- Include the time and username that initiated the update in each DB record
+
+## ![✔] OWASP A7: Cross-Site-Scripting (XSS)
+
+- Use templating engines or frameworks that automatically escape XSS by design, such as EJS, Pug, React, or Angular. Learn the limitations of each mechanisms XSS protection and appropriately handle the use cases which are not covered
+- Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities
+- Applying context-sensitive encoding when modifying the browser document on the client-side acts against DOM XSS
+- Enabling a Content-Security Policy (CSP) as a defense-in-depth mitigating control against XSS
+
+
+<br/><br/><br/>

sections/security/dependencysecurity.spanish.md

@@ -0,0 +1,53 @@
+# Constantly and automatically inspect for vulnerable dependencies
+
+### One Paragraph Explainer
+
+The majority of Node.js applications rely heavily on a large number of third party modules from npm or Yarn, both popular package registries, due to ease and speed of development. However, the downside to this benefit is the security risks of including unknown vulnerabilities into your application, which is a risk recognised by its place in the OWASP top critical web application security risks list.
+
+There is a number of tools available to help identify third-party packages in Node.js applications which have been identified as vulnerable by the community to mitigate the risk of introducing them into your project. These can be used periodically from CLI tools or included as part of your application's build process.
+
+### Table of Contents
+
+- [NPM audit](#npm-audit)
+- [Snyk](#snyk)
+- [Greenkeeper](#greenkeeper)
+
+### NPM Audit
+
+`npm audit` is a new cli tool introduced with NPM@6.
+
+Running `npm audit` will produce a report of security vulnerabilities with the affected package name, vulnerability severity and description, path, and other information, and, if available, commands to apply patches to resolve vulnerabilities.
+
+![npm audit example](/assets/images/npm-audit.png)
+
+🔗 [Read on: NPM blog](https://docs.npmjs.com/getting-started/running-a-security-audit)
+
+### Snyk
+
+Snyk offers a feature-rich CLI, as well as GitHub integration. Snyk goes further with this and in addition to notifying vulnerabilities, also automatically creates new pull requests fixing vulnerabilities as patches are released for known vulnerabilities.
+
+Snyk's feature rich website also allows for ad-hoc assessment of dependencies when provided with a GitHub repository or npm module url. You can also search for npm packages which have vulnerabilities directly.
+
+An example of the output of the Synk GitHub integration automatically created pull request:
+![synk GitHub example](/assets/images/snyk.png)
+
+🔗 [Read on: Snyk website](https://snyk.io/)
+
+🔗 [Read on: Synk online tool to check npm packages and GitHub modules](https://snyk.io/test)
+
+### Greenkeeper
+
+Greenkeeper is a service which offers real-time dependency updates, which keeps an application more secure by always using the most update to date and patched dependency versions.
+
+Greenkeeper watches the npm dependencies specified in a repository's `package.json` file, and automatically creates a working branch with each dependency update. The repository CI suite is then run to reveal any breaking changes for the updated dependency version in the application. If CI fails due to the dependency update, a clear and concise issue is created in the repository to be auctioned, outlining the current and updated package versions, along with information and commit history of the updated version.
+
+An example of the output of the Greenkeeper GitHub integration automatically created pull request:
+
+![synk github example](/assets/images/greenkeeper.png)
+🔗 [Read on: Greenkeeper website](https://greenkeeper.io/)
+
+### Additional resources
+
+🔗 [Rising Stack Blog: Node.js dependency risks](https://blog.risingstack.com/controlling-node-js-security-risk-npm-dependencies/)
+
+🔗 [NodeSource Blog: Improving npm security](https://nodesource.com/blog/how-to-reduce-risk-and-improve-security-around-npm)