Features like this one typically represent big ideas you have for your product. They can be defined around broad capabilities you'd like to enable, or user needs you'd like to address. The truth is, features will evolve as they progress through your prioritization process and you get a better sense for the solution they entail, and it's ok to update their name and description as you go.
Each field below represents a data field that you can also add as a column on your Features board to help you prioritize and plan.
On the Insights tab, you'll see everyone who's ever requested this feature, what they said about, and how important it is to them – based on user insights linked to this feature.
You can also add this feature as a card on your Portal to allow colleagues and customers to vote and provide feedback on it.
h1. WHY
In 2021 we want to provide features to secure Cloud Native Apps. In order to raise taint vulnerabilities, we need to know how user data can reach Cloud Functions.
Serverless framework is a popular framework to build Cloud Native Apps with 39.4K stars on GitHub. For this reason it should be the first framework we support to raise real vulnerabilities on Cloud Native Apps.
WHAT
Use Case
As a developer building a Cloud Native App with the Serverless framework I want to be sure I don't have any Injection Vulnerabilities.
At first, we want to detect vulnerabilities in:
AWS Lambdas configured in a serverless.yml file
for Lambdas written in JavaScript\/TypeScript
Solution
SonarSecurity needs to understand:
which function is an AWS Lambda
which parameter can be tainted by a user and for that Serverless files (serverless.yaml) should be scanned
Configuration
The following section explains what has to be done in regards to the configuration file of the Serverless framework.
Format
The configuration can be stored in the following formats:
The YAML format is used in the documentation for examples and judging from public GitHub repositories and searches on SourceGraph it is used by a vast majority of developers, thus it is sufficient to concentrate on YAML in this MMF.
There can be multiple configuration files in a project, so all directories should be checked. The configuration file can be specified with a command line parameter, though it defaults to serverless.yml and serverless.yaml, so it is sufficient to expect one of those names.
All paths are relative to the configuration file, so there should be no uncertainty when it comes to resolving any paths.
Events
Events and their handlers are declared under the key functions, followed by an arbitrary name. There are 2 type of events that are used to specify handlers for HTTP requests, specified as an array element under the key events: http and httpApi. When the event occurs the exported function some\_value\_c of module some\_value\_b, specified under the key handler, is executed.
mock integrations should be discarded. The other 4 integrations do not have to be differentiated for now. It is worth noting that lambda\-proxy allows to configure path parameters but it is not necessary to detect these in the configuration, since passed parameters will be part of the event object.
The following properties of event should be considered tainted:
headers
queryStringParameters
pathParameters
requestContext.identity.userAgent
body
headers and requestContext.identity.userAgent should be excluded from S5145 since they can not contain newline characters. All sources should be excluded from S6096.
Wrapper
The serverless\-http module might be used to handle events. It is a wrapper that allows the developers to use frameworks like Express, Koa, or Restana.
The configuration does not have to be considered here, the security analyzer is already able to scan applications that use serverless\-http.
Features like this one typically represent big ideas you have for your product. They can be defined around broad capabilities you'd like to enable, or user needs you'd like to address. The truth is, features will evolve as they progress through your prioritization process and you get a better sense for the solution they entail, and it's ok to update their name and description as you go.
Each field below represents a data field that you can also add as a column on your Features board to help you prioritize and plan.
On the Insights tab, you'll see everyone who's ever requested this feature, what they said about, and how important it is to them – based on user insights linked to this feature.
You can also add this feature as a card on your Portal to allow colleagues and customers to vote and provide feedback on it.
h1. WHY
In 2021 we want to provide features to secure Cloud Native Apps. In order to raise taint vulnerabilities, we need to know how user data can reach Cloud Functions.
Serverless framework is a popular framework to build Cloud Native Apps with 39.4K stars on GitHub. For this reason it should be the first framework we support to raise real vulnerabilities on Cloud Native Apps.
WHAT
Use Case
As a developer building a Cloud Native App with the Serverless framework I want to be sure I don't have any Injection Vulnerabilities.
At first, we want to detect vulnerabilities in:
AWS Lambdas configured in a
serverless.yml
filefor Lambdas written in JavaScript\/TypeScript
Solution
SonarSecurity needs to understand:
which function is an AWS Lambda
which parameter can be tainted by a user and for that Serverless files (serverless.yaml) should be scanned
Configuration
The following section explains what has to be done in regards to the configuration file of the Serverless framework.
Format
The configuration can be stored in the following formats:
||File format||Default name||Hits in [sourcegraph.com|[[https:\/\/sourcegraph\.com\]|](https://sourcegraph%5C.com%5C%5D%7C)[https:\/\/sourcegraph\.com%5D%7C%7C](https://sourcegraph.com%5D%7C%7C)]
|YAML|serverless.yml \/ serverless.yaml|~1K|
|JSON|serverless.json|7|
|JS|serverless.js|50|
|TS|serverless.ts|3|
The YAML format is used in the documentation for examples and judging from public GitHub repositories and searches on SourceGraph it is used by a vast majority of developers, thus it is sufficient to concentrate on YAML in this MMF.
There can be multiple configuration files in a project, so all directories should be checked. The configuration file can be specified with a command line parameter, though it defaults to
serverless.yml
andserverless.yaml
, so it is sufficient to expect one of those names.All paths are relative to the configuration file, so there should be no uncertainty when it comes to resolving any paths.
Events
Events and their handlers are declared under the key
functions
, followed by an arbitrary name. There are 2 type of events that are used to specify handlers for HTTP requests, specified as an array element under the keyevents
:http
andhttpApi
. When the event occurs the exported functionsome\_value\_c
of modulesome\_value\_b
, specified under the keyhandler
, is executed.The structure of the configuration depends on the selected ingeration.
There are currently 5 integrations:
lambda-proxy (aliases: aws-proxy, aws_proxy)
lambda (aliases: aws)
http
http-proxy (aliases: http_proxy)
mock
mock
integrations should be discarded. The other 4 integrations do not have to be differentiated for now. It is worth noting thatlambda\-proxy
allows to configure path parameters but it is not necessary to detect these in the configuration, since passed parameters will be part of theevent
object.Variables
Serverless supports [variables|[[https:\/\/www\.serverless\.com\/framework\/docs\/providers\/aws\/guide\/variables\/\]|](https://www%5C.serverless%5C.com/framework/docs/providers/aws/guide/variables/%5C%5D%7C)[https:\/\/www\.serverless\.com\/framework\/docs\/providers\/aws\/guide\/variables\/%5D](https://www.serverless.com/framework/docs/providers/aws/guide/variables/%5D)] that can be used to dynamically replace values in the configuration. The following types of variables should be supported.
Self-reference
${self:x
} can be used to reference variables in the same file.Files
${file(y):x
} can be used to reference variables in another file.Handler
The following section explains what has to be done in regards to the JavaScript code that is referenced by the configuration file.
Direct
The first parameter of the function
some\_value\_c
that is specified by the configuration is an object and partially tainted.The following properties of
event
should be considered tainted:headers
queryStringParameters
pathParameters
requestContext.identity.userAgent
body
headers
andrequestContext.identity.userAgent
should be excluded from S5145 since they can not contain newline characters. All sources should be excluded from S6096.Wrapper
The
serverless\-http
module might be used to handle events. It is a wrapper that allows the developers to use frameworks like Express, Koa, or Restana.The configuration does not have to be considered here, the security analyzer is already able to scan applications that use
serverless\-http
.Measuring
The MMF was successfully implemented when the issues in [this|[[https:\/\/github\.com\/SonarSource\/security\-expected\-issues\/tree\/master\/javascript\/lambdas\/serverless\]|](https://github%5C.com/SonarSource/security%5C-expected%5C-issues/tree/master/javascript/lambdas/serverless%5C%5D%7C)[https:\/\/github\.com\/SonarSource\/security\-expected\-issues\/tree\/master\/javascript\/lambdas\/serverless%5D](https://github.com/SonarSource/security-expected-issues/tree/master/javascript/lambdas/serverless%5D)] test cases are raised.
More info: http://bit.ly/getting-started-with-features