Protect your app with Sqreen

Sqreen uses several layers of security to protect your applications, microservices, and APIs from malicious attacks.

Sqreen categorizes the layers according to the way they monitor the activity inside your app:

• Application protection
• User protection

Application protection

From within your app, Sqreen uses multiple layers to monitor request-based and traffic-based activity in your application for suspicious activity. Notably, Sqreen does not redirect traffic coming in to your app in order to monitor activity.

In-App Web Application Firewall (In-App WAF)

As its name implies, Sqreen’s In-App WAF operates as a web application firewall from within your application, microservice, or API. Like a WAF that exists outside an app, Sqreen’s In-App WAF inspects all incoming traffic and uses pattern-matching to detect and block malicious traffic. However, unlike an external WAF that applies a broad range of rules to inspect traffic, the In-App WAF uses the full context of your application – its databases, its frameworks, its programming language – to narrowly apply the most efficient set of inspection rules.

For example, if your app is in PHP and uses SQL databases, the In-App WAF inspects incoming traffic only for PHP-relevant and SQL-relevant patterns. This contextual efficiency not only reduces the amount of inspection work, it drastically reduces the false positive rate of an external WAF. Casting a wide net, the In-App WAF is the first line of defense in the early detection of malicious attackers.

In-App WAF custom rules

An In-App WAF custom rule enables you to log or block specific types of requests to your app according to conditions and actions you define. You can use these rules to track or block any request that matches a pattern you specify, whether it is matching a specific value in a field, or a combination of fields, or an absence of a value in a field.

The following examples illustrate how you can use custom rules to fine-tune the behavior of your In-App WAF.

• To enforce your internal business best practices, you can create a custom rule to block every request to an app that is missing an authentication header.
• While your engineering team works to patch a known vulnerability in an app, you can create a custom rule to act as a virtual patch, blocking requests that attempt to exploit the vulnerability before it is fixed.
• Where your app uses legacy but legitimate behavior that falsely triggers a security event, create a custom rule to allow the legacy behavior to pass.

Learn more about custom rules in the Log or block requests documentation.

Security Headers

A browser’s HTTP response headers mainly contain metadata that instruct a website how to interact with the browser. However, you can include security rules with the response headers that a browser uses to protect itself against specific kinds of attacks. Use Sqreen to set up several HTTP security headers to protect against clickjacking, MIME sniffing, Cross-site Scripting (XSS), and referrer leakage.

From the Sqreen Dashboard, you can make one-click changes to the headers without redeploying your app or making changes in its code. Regardless of your app’s technology, programming language, or framework, there is no need to change the code of the app. Be aware that any changes you make to the security headers in Sqreen override any existing security headers set in your app’s code, with the exception of any headers set on the network such as in a Content Delivery Network (CDN).

Content Security Policy

A Content Security Policy (CSP) is an HTTP response header that works to prevent specific types of attacks, primarily Cross-site scripting (XSS). When a browser simply trusts all sources (websites), it executes any script that it receives and is, therefore, vulnerable to executing malicious script. Sqreen enables you to monitor the content sources with which a browser interacts so you can build a content security policy that specifies sources a browser can trust. With a CSP in place, a browser only executes scripts that it receives from trusted sources.

Because setting up a CSP can be challenging, Sqreen uses a three-step, interactive process to help you set up a CSP on your app:

1. From the Sqreen Dashboard, access an audit of the sources that request assets in your app. On launch, Sqreen already started collecting this data in monitoring mode.
2. Examine Sqreen’s initial triage of obviously malicious versus potentially legitimate sources.
3. Using the audit and triage data, craft and enforce a CSP in blocking mode.

Runtime Application Self-Protection (RASP)

Sqreen’s RASP protects the app from real-time attacks from within the app’s own runtime environment, hence the name. To do this, RASP correlates the context and semantics of a request to look for anomalies.

For example, imagine your app uses a SQL database and you have installed Sqreen to protect your app. The microagent you installed inside the app hooked into the SQL driver methods so it can check the queries going into the database. Before a request reaches the database, RASP uses a SQL parser to determine if the database will interpret the request parameters as executable SQL code. If the semantics of the query are executable, such as SELECT * FROM Users WHERE UserId = 105 OR 1=1;, the Security Engine detects a SQL injection vulnerability and blocks or logs the information. (Whether Sqreen blocks the query or simply logs the metadata depends upon how you configure its behavior in the Sqreen Dashboard.)

Sqreen designed its RASP technology with developers in mind: it is production-ready and works with applications written in several programming languages – not just Java. This enables you to deploy Sqreen across multiple applications in multiple environments without the extra work to tweak and configure its parameters for each app.

Core Protection and Smart Stack Detection

On initial launch from inside your app, Sqreen collects information about the application’s stack such as its framework, databases, and programming language. Using this context-specific information, Sqreen applies its Core Protection to your app using In-App WAF and RASP.

• In-App WAF: Sqreen enables safe rules (rules that have proven valuable to customers) in blocking mode. Sqreen enables unsafe rules (rules that that regularly trigger false positives) in logging mode to monitor activity for early detection of an attack. Because it knows the full context of your app, Sqreen knows which rules to apply to protect your app while limiting the number of false positive results.

• RASP: Sqreen enables a core set of vulnerability protections including SQL injection, Local File Inclusion, Shell Injection, Shellshock, and Reflected Cross-site scripting (XSS).

As your app evolves, Sqreen uses Smart Stack Detection to expand and extend the rules it applies using In-App WAF and RASP. When the context of your app’s stack dictates, Sqreen continues to enable safe rules in blocking mode. Smart Stack Detection, therefore, continuously monitors your app to ensure that it applies the best and most efficient rules for your app.

Passlist and Denylist

You can use a passlist or denylist to permanently allow or disallow an IP address, or range of addresses, access to your app. For example, you may wish to add internal IP addresses to your passlist, or IP addresses that regularly run security audits on your app. To the passlist, you can also add specific file paths to ensure uninterrupted access. Note that any requests that passlisted IP addresses or paths make to your app do not count against your request quota.

From the Sqreen Dashboard, navigate to Settings > Passlist, or Settings > Denylist.

User protection

With the help of an SDK for User Monitoring and several built-in integrations with authentication middleware (Devise for Ruby, Django for Python, Passport for Node.js), Sqreen monitors user behavior for signs of Account Takeover (ATO) and targeted attacks. Using the SDK and/or the built-in integrations, you can create Security Automation Playbooks to automate your app's response to threats.

Several Pre-defined Playbooks enable you to begin monitoring the activity in your app for signs of attack and take action to log the activity or block requests. The following examples illustrate the automated responses and User Monitoring flags that the pre-defined playbooks apply.

Playbook	Description	User Monitoring Flag
Block users connecting from TOR	This Playbook recognizes TOR IP addresses and blocks those IPs from accessing your app.	TOR user
Login with multiple geos	This Playbook recognizes when the user credentials of a non-shared account are used to log in to your app from two different locations at nearly the same time.	Multiple geo
Login with shared account	This Playbook recognizes when the user credentials of a shared account are used to log in to your app from two different locations at nearly the same time. Because the credentials are known to be shared amongst legitimate users, this may not be malicious behavior, but it is worth logging and tracking.	Shared account
Unusual volume of signups	This Playbook identifies an anomaly in the volume of new user accounts created on your app.	n/a
Monitor admin login from overseas	This Playbook tracks the logins of your app's administrators when the logins originate from locations beyond where your administrators normally live and work.	n/a

Multiple layers of protection

Sqreen combines multiple layers of protection to monitor requests and keep your application safe from different types of threats and vulnerabilities. For several threats, Sqreen uses more than one layer to monitor and protect your app.

Skip to the Threats and vulnerabilities section to learn how Sqreen protects against each threat.

Vulnerability	In-App WAF	CSP & SH	User Monitoring	RASP
Account Takeover (ATO)			x
Clickjacking		x
Cross-site Scripting (XSS), Reflected and Stored	x	x
Local File Inclusion (LFI)	x			x
MIME sniffing		x
NoSQL Injectiong	x			x
Referrer Leakage		x
Remote Code Execution (RCE)	x
Security Scanners	x
Server-side Request Forgery (SSRF)	x			x
Shell Injection	x			x
Shellshock	x			x
SQL Injection	x			x

Configuration and performance

As a user, you interact with the Sqreen Platform via a web app called the Sqreen Dashboard. Use the Protection Status page of your application to examine how Sqreen is monitoring and protecting your app from threats and vulnerabilities. Use the Configuration page to set Sqreen’s security parameters.

From the Sqreen Dashboard, you can also monitor and adjust Sqreen’s performance inside your app. Access the Settings to apply a limit to the time Sqreen can take to examine requests. Sqreen sets the maximum execution duration per request to 20 milliseconds by default.

Threats and vulnerabilities

Account Takeover (ATO)

OWASP Top 10:	A2:2017-Broken Authentication
Security Layers:	User monoitoring
Configuration:	Sqreen Dashboard > Configuration > Account Takeover > Account takeover detection

An attacker uses Account Takeover to compromise user accounts. Attackers use several techniques in ATO attacks:

• credential stuffing, where an attacker uses a leaked list of login credentials to try to log in to accounts on numerous websites
• brute force attack, where an attacker submits many passwords to guess the correct one
• dictionary attack, where an attacker uses a bot to repeatedly use common passwords, or words in a dictionary as passwords to try to log in to user accounts

When they gain access, they have taken over the account and can do as they wish. This can lead to fraud and issues with the business logic of your application.

To guard against ATO attacks, use Sqreen’s built-in authorization middleware integrations (Devise for Ruby, Django for Python, Passport for Node.js), or install and configure Sqreen’s SDK for User Monitoring. Use the SDK to implement three simple methods: trackLogin, trackSignup and identify. The Sqreen microagent can then collect events associated with those methods which it sends to the Sqreen Platform for analysis. When the platform detects suspicious login activity, it sends a security response to the microagent to instruct the Security Engine to block or log the suspicious requests. Using the information Sqreen collected, you can configure Sqreen’s ATO protection to temporarily or permanently block specific IPs or user accounts.

Further, you can use Security Automation Playbooks to automate the way your app responds to ATO threats and how it takes action to recover compromised accounts.

Clickjacking

OWASP Top 10:	n/a
CWE:	CWE-451: User Interface (UI) Misrepresentation of Critical Information
Security Layers:	Security Headers
Configuration:	Sqreen Dashboard > Configuration > Security Headers

An attacker uses clickjacking to trick an end user into clicking on an innocent-looking but maliciously hijacked object such as a button or link on a web page. Once clicked, the attacker can potentially access sensitive user information and take control of an end user’s computer.

To guard against clickjacking, Sqreen uses the X-Frame-Options header in your app’s response to a client-side request. It declares your website’s framing policy which prevents framing or applies boundaries to the ways it allows framing to occur. For example, you can use Sqreen to configure the header’s value so that it allows your website to render another HTML document in a frame only if the other document exists within the same domain.

Reflected Cross-Site Scripting (XSS) and Stored Cross-Site Scripting (XSS)

OWASP Top 10:	A7:2017-Cross-Site Scripting (XSS)
Security Layers:	In-App WAF + Content Security Policy + RASP (reflected XSS only)
Configuration:	Sqreen Dashboard > Configuration > In-App WAF > XSS Injections Sqreen Dashboard > Configuration > Security Headers Sqreen Dashboard > Configuration > Content Security Policy

An attacker uses a reflected XSS attack (also known as a non-persistent XSS attack) to inject malicious content into a request between a web client and web app server. A server is vulnerable to executing the malicious script if it does not sanitize the HTML query parameters before executing the script to render a web page. In such a case, a vulnerable server executes the injected script and can expose sensitive page content.

In a stored XSS attack (also known as a persistent XSS attack), a vulnerable server not only executes malicious script, it stores the malicious script to render and display contaminated pages to other web app users.

To guard against XSS attacks, Sqreen hooks into the rendering methods of the app’s template engine(s). Before the app renders the template, Sqreen checks the request for arbitrarily inserted HTML or JavaScript code. When it finds malicious code, Sqreen acts to block or log the event, according to your configuration. Sqreen's In-App WAF layer guards against reflected and stored XSS attacks while the RASP layer guards against reflected XSS only.

Note that if you configure Sqreen to block XSS requests to your app, Sqreen does not block the end user from accessing your app. Instead, Sqreen escapes the malicious user inputs, then renders the page to the end user. With Sqreen monitoring your app for XSS, your app always renders the page, without impacting the template.

Local File Inclusion (LFI)

OWASP Top 10:	A1:2017-Injection
Security Layers:	RASP + In-App WAF
Configuration:	Sqreen Dashboard > Configuration > In-App WAF > Local File Inclusion

An attacker uses LFI, also known as file path traversal, to access a web app server's file system. With such access, an attacker can obtain sensitive information such as credentials for back-end systems or the application’s code, or initiate a Denial of Service (DoS) attack. Where an LFI attack occurs via module inclusion (such as include in PHP, or require in NodeJS), the attacker can execute arbitrary code in your app.

To guard against LFI, Sqreen hooks into the file access methods in your app to monitor requests for signs of attack, such as:

• the path starts at the root filesystem (/on UNIX systems) and the user injects the whole path
• the user input traverses back to the root file system of the server (the attacker injected a ../ in the path)

When it detects signs of LFI, Sqreen acts to block the request or log the event, according to your configuration.

MIME Sniffing

OWASP Top 10:	n/a
CWE:	n/a
Security Layers:	Security Headers
Configuration:	Sqreen Dashboard > Configuration > Security Headers

An attacker uses MIME sniffing to disguise the file type of content they upload to a website. A vulnerable website does not demand that a file’s content type be specified in its header, so the website may upload disguised, arbitrary files.

To guard against arbitrary uploads to your web app, Sqreen uses the X-Content-Type-Options header in your app’s response to a client-side request. By setting the value to nosniff, it disables a browser’s MIME sniffing capabilities and demands that a browser use the original MIME type of a file as defined by its source.

NoSQL Injection

OWASP Top 10:	A1:2017-Injection
Security Layers:	In-App WAF + RASP
Configuration:	Sqreen Dashboard > Configuration > In-App WAF > NoSQL Injections

An attacker uses NoSQL Injection to gain access to data in a NoSQL, or non-relational, database. A NoSQL injection occurs when a query relies on non-sanitized user inputs. An attacker can alter the structure of the query to return more or different data than expected.

MongoDB is an example of a NoSQL database that uses JSON to represent a query instead of SQL. When building a JSON database query, an attacker injects operators to alter the structure of the query. For example, consider a query: {"hidden": {$eq: true},"groups":"?","ref":"?"} The user input through the HTTP request query string provides the value for the hiddenfield. An attacker could inject the value {"$ne":"?"} in the hidden field to retrieve all documents regardless of their hidden status.

To guard against NoSQL Injection, Sqreen hooks into the NoSQL driver methods in your app to monitor the queries that the database is about to execute. It uses a NoSQL parser to look for keywords in the query. Rather than monitoring for literal matches, Sqreen monitors requests for sensitive keywords in both the user parameter and the query. If the parser finds a keyword, Sqreen checks for accidental collision (two variables with identical names), and whether the user parameter fits the context of the query. When those checks fail, Sqreen acts to block the query or log the event, according to your configuration.

Referrer Leakage

OWASP Top 10:	n/a
CWE:	n/a
Security Layers:	Security Headers
Configuration:	Sqreen Dashboard > Configuration > Security Headers

An attacker uses referrer leakage (also known as cross-domain referrer leakage) to draw sensitive information out of a URL. When a browser goes from a page to another, it includes the address of its originating page in a HTTP header called the referrer. If the browser goes to a page outside its own domain, it still includes the referrer. Where a URL contains sensitive information in its request, such as a user’s session token, the referrer header allows the information to leak to a different, potentially untrustworthy, domain.

To guard against referrer leakage, Sqreen uses the Referrer Policy header in your app’s response to a client-side request. It declares your website’s policy for withholding a referrer.

Remote Code Execution (RCE)

OWASP Top 10:	A9:2017-Using Components with Known Vulnerabilities
Security Layers:	In-App WAF
Configuration:	Sqreen Dashboard > Configuration > In-App WAF > PHP Injections

An attacker uses RCE to remotely gain access to an application’s web server so as to run arbitrary code. For example, programming languages often expose APIs to let developers execute a string containing code. Those eval( )-like functions are an opening for an attacker to remotely instruct your app to execute untrusted code and compromise the application’s server.

To guard against RCE, Sqreen monitors requests to ensure that user input does not contain executable commands. Where it detects such commands, Sqreen blocks the request.

Security Scanners

OWASP Top 10:	A1:2017-Injection A6:2017-Security Misconfiguration A9:2017-Using Components with Known Vulnerabilities
Security Layers:	In-App WAF
Configuration:	Sqreen Dashboard > Configuration > In-App WAF > Security Scanners

An attacker uses security scanners as automated tools to discover vulnerabilities in your app. Although not harmful in themselves, scanners guide an attacker toward potential weaknesses in your application.

To guard against scanning, Sqreen blocks requests where the user agent matches a specific RegEx. For example, to protect against Black Widow scans, Sqreen blocks requests where the user agent matches ^Arachni\/v.

Server-side Request Forgery (SSRF)

OWASP Top 10:	n/a
CWE:	CWE-918: Server-side Request Forgery
Security Layers:	In-APP WAF + RASP
Configuration:	Sqreen Dashboard > Configuration > RASP > Server Side Request Forgery

An attacker uses SSRF to manipulate a web app’s server into accessing resources and data it would not normally access. Where a normal request in a URL might, say, retrieve a list of company products from a database, an attacker can adjust the URL to trick the app server into retrieving information from other resources that the web app has access to. For example, an attacker could adjust a request to get the app server to query a credential manager to retrieve sensitive data.

To guard against SSRF, Sqreen hooks into your app’s networking libraries to monitor requests and runs checks and heuristics on URLs. Specifically, Sqreen checks the format of the URL to block any bypass attempts or parameter injection, and it checks the domain against a denylist. When it detects signs of SSRF, Sqreen acts to block the request or log the event, according to your configuration.

Shell Injection

OWASP:	Command Injection
CWE:	CWE-77: Improper Neutralization of Special Elements used in a Command CWE-78: Improper Neutralization of Special Elements used in an OS Command
Security Layers:	In-APP WAF + RASP
Configuration:	Sqreen Dashboard > Configuration > RASP > Shell Injection

An attacker uses shell injection to execute arbitrary commands on the web app server. This enables an attacker to obtain unauthorized access to the app and anything the app has access to.

To guard against shell injection, Sqreen monitors HTTP requests for execution commands by parsing the commands that the shell is about to execute. Sqreen looks for non-sanitized commands such as ls, touch, cat, rm that a user has injected into the command. When it detects an executable command, Sqreen acts to block the request or log the event, according to your configuration.

Shellshock

OWASP Top 10:	A9:2017-Using Components with Known Vulnerabilities
Security Layers:	RASP
Configuration:	Sqreen Dashboard > Configuration > RASP > Shellshock

Similar to a shell injection, an attacker uses Shellshock, also known as Bashdoor, to execute arbitrary commands on the server. By taking advantage of a series of vulnerabilities in Bash, an attacker obtains unauthorized access to the app and anything the app has access to.

To guard against shell injection, Sqreen monitors the environment variables of a command that the shell is about to execute. Sqreen looks for commands such as : () { :;}; cat /etc/passwd that a user has injected into the command. When it detects an executable command, Sqreen acts to block the request or log the event, according to your configuration.

SQL Injection

OWASP Top 10:	A1:2017-Injection
Security Layers:	In-APP WAF + RASP
Configuration:	Sqreen Dashboard > Configuration > In-App WAF > SQL Injections

An attacker uses SQL Injection to gain access to data in a relational database that relies on SQL to represent a query. A SQL injection occurs when a query relies on non-sanitized user inputs. An attacker can alter the structure of the query to return more or different data than expected.

For example, consider a query: SELECT first_name, last_name, address, phone_number FROM users WHERE id = '$user_id'

The user input through the HTTP request query string provides the value for $user_id. An attacker could inject a value like ' OR 1 = 1# the user_id field to retrieve all records. To guard against SQL Injection, Sqreen hooks into the SQL driver methods in your app to monitor the queries that the database is about to execute. Then, it uses a SQL parser to check whether the database will interpret the HTTP request parameters as executable SQL code. When it detects executable code, Sqreen acts to block the query or log the event, according to your configuration.

For specific use cases, app developers may implement SQL injection vulnerabilities by default in the application. This is especially true for Admin panels. Where this is the case, configure Sqreen to Log Only mode for SQL Injections.

Security Automation Playbooks

A Security Automation Playbook enables you to customize and automate your app’s response to threats. Without manually coding the logic, you can use playbooks to extend Sqreen’s ability to protect your app from more than just the generic threats and vulnerabilities; you can configure it to protect your app’s business logic.

A playbook consists of three parts:

• A trigger is a condition (or multiple conditions) that you set based on a threshold of events that occur in a specific timeframe by a specific actor (user or IP address). For example, When app.sqreen.plugins.attack is performed 3 or more times over a period of 10 minutes by an IP.
• A security response is an action that you define to instruct Sqreen to block or redirect the bad actor to a specific page. For example, Block the IP for 5 minutes.
• A notification is an action that you customize to instruct Sqreen on how to notify you when user activity triggers the playbook. For example, Send a Slack notification to sec-admin-channel immediately.

After you install the SDK for User Monitoring and configure the playbook in the Sqreen Dashboard, Sqreen begins tracking activity using the following sources:

• the security signals the microagent collects
• the custom business-logic security events that the microagent collects using Sqreen.track('') (requires SDK for User Monitoring)

The microagent sends the security signals and events it collects to the Sqreen Platform with every heartbeat. The platform analyses the data it receives. If the user activity triggers a playbook, the platform sends the security response to the microagent during the next heartbeat. The Security Engine inside the microagent then takes action according to the playbook’s security response, like blocking an IP address for five minutes. Within two heartbeat cycles, or about 40 seconds, the Security Engine takes action to protect your app from attack.

Learn more about How Sqreen works: In depth.

Learn more about Security Automation Playbooks.

Sqreen Webhooks

You can use webhooks to integrate your playbooks with third-party products to further automate your business processes. A webhook connects Sqreen to an external service which Sqreen notifies when it detects a specific security event. When it detects an event, Sqreen sends a POST request to the URL you provide.

For example, you can use Sqreen Webhooks to:

• monitor suspicious login activities for admin accounts
• send malicious IPs to a network-layer firewall
• prevent password reset abuses
• send a notification when the same IP signs up more than X times
• block signups from TOR
• prevent login from a specific country

Learn more about Sqreen Webhooks.

Read next

• Observe your app with Sqreen
• How Sqreen works
• Quick start guide
• Log or block requests
• Security Automation Playbooks
• Sqreen Webhooks