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:

||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 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.


functions:
some\_value\_a:
handler: some\_value\_b.some\_value\_c
events:
\- http:
\- httpApi:

The structure of the configuration depends on the selected ingeration.


functions:
some\_value\_a:
integration: lambda\-proxy

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 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.

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.


custom:
events:
\# ...

functions:
hello:
handler: handler.hello
events:
\- ${self:custom.events}

Files

${file(y):x} can be used to reference variables in another file.


functions:

- ${file(some/file.yml):functions}


functions:
some\_value\_a:
\# ...

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.


module.exports.some\_value\_c = function (event, context, callback) {
const response = {
statusCode: 200,
body: JSON.stringify({ message: 'Hello World!' }),
};
callback(null, response);
};

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.


const serverless = require('serverless\-http');
const express = require('express');

const app = express();
app.get('/', function (req, res) {
eval(req.query.foo); // Noncompliant
});

module.exports.handler = serverless(app);

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

AlinaVasylieva / cypress-tutorial

Rich text formatting (sample feature) #4