Vulnerabilities Project

Site Three: http://testhtml5.vulnweb.com

Technologies Used In This Site:

Tech (scanned by zofixer.com:)

Amazon S3
Amazon Web Services
Angular JS
Bootstrap
Google Font API
Google Hosted Libraries
jQuery
jQuery CDN
Nginx

Vulnerabilities to check for:

SQL Injection (SQLI)

Explanation:

"SQL Injection flaws are introduced when software developers create dynamic database queries constructed with string concatenation which includes user supplied input. To avoid SQL injection flaws is simple. Developers need to either: a) stop writing dynamic queries with string concatenation; and/or b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query."

From: OWASP SQL Injection Prevention

Solution(s):

Parameterized Queries & Prepared Statements (server side)

"SQL Injection is best prevented through the use of parameterized queries. The following chart demonstrates, with real-world code samples, how to build parameterized queries in most of the common web languages. The purpose of these code samples is to demonstrate to the web developer how to avoid SQL Injection when building database queries within a web application."

From OWASP CheatSheet Query Parameterization Example of Parameterization in Java (server side)

String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );

ORM - Object Relational Mapping (server side)

"The use of an object-relational mapping (ORM) layer is also something you can consider. An ORM layer transforms the data from the database into objects and vise-versa. Using an ORM library reduces explicit SQL queries and, therefore, much less vulnerable to SQL injection."

From: GlobalDots: 8 Best Practices To Prevent Injection Exmaple from Django ORM

Entry.objects.filter(pub_date__year=2006)

Explanation: Because the orm accepts specific query parameters it does not open the door to the user being able to create / inject their on sql query that the database then executes. The information has to match the specific items being searched for through the ORM

Input Validation(client side)

The main line of defense on the client side to prevent sql injection is input validation. It is meant to be in addition to parameterization / use of an orm to perform sql queries. It is not a primary line of defense. That being said validation of the input can require the user to match specific information in the html so that can cannot just send whatever information they want to send. Validations can include: data type validators, arrays of allowed or hard-coded values, regular expressions for matching specific patterns, min or max values / ranges and many more. Validation can also be checked on the backend after the information is submitted.

Examples of HTML Input Validation:

<input type="text" id="choose" name="i-like" required minlength="6" maxlength="6" />

<input type="number" id="number" name="amount" value="1" min="1" max="10" />

<input id="choose" name="i-like" required pattern="[Bb]anana|[Cc]herry" />

Cross Site Scripting (XSS)

Explanation:

"Cross-Site Scripting (XSS) is a misnomer. The name originated from early versions of the attack where stealing data cross-site was the primary focus. Since then, it has extended to include injection of basically any content, but we still refer to this as XSS. XSS is serious and can lead to account impersonation, observing user behaviour, loading external content, stealing sensitive data, and more."

From: OWASP Cross Site Scripting Prevention

Solution(s)

XSS Defense Philosophy

"For XSS attacks to be successful, an attacker needs to insert and execute malicious content in a webpage. Each variable in a web application needs to be protected. Ensuring that all variables go through validation and are then escaped or sanitized is known as perfect injection resistance. Any variable that does not go through this process is a potential weakness. Frameworks make it easy to ensure variables are correctly validated and escaped or sanitised. However, frameworks aren't perfect and security gaps still exist in popular frameworks like React and Angular. Output Encoding and HTML Sanitization help address those gaps."

From: OWASP Cross Site Scripting Prevention

Output Encoding / Character Escaping, and Input Validation

Output Encoding, Character Escaping, and Input Validation are top defensive strategies to minimize and prevent cross site scripting attacks. When user input that is being displayed as output to the UI there exists an opportunity for a user to type in code that can end up being run because the computer doesn't recognize or know that it is just meant to be displayed as a string, but truly ends up being run as code. Hijackers can exploit this by typing in the code they wish to run. For example

Most frameworks and frontend libraries have output character escaping / security measures built into their technologies. React and Django are two such examples. PHP however, does not.

PHP Code Example For Hangling Output Character Escaping:

PHP has functionality built into its system that allows for character escaping, but it is not automatically executed or used:

<?php function escape($string) { return htmlspecialchars($string, ENT_QUOTES) } ?>

<p>Hello <?php echo escape($name)?>;<p>

Explanation:

When a variable containing user or external input is going to be output in the UI.. if the output contains what looks like actual code (ex: <script>alert(1)<script>) that code will be read by the browser as being actual code to run unless those special html characters (and others) are intentionally told to output as actual test and not to turn it into code.

The output escaping function will parse / convert each variable / user info / output so that it cannot output anything other than a regular string. It is a primary layer of preventing cross site scripting. While user input can be filtered before saving to the database or returning the information back to the frontend, there are other ways to still directly change the output right before it is actually output. Therefore the best place to prevent XSS is right before it is actually output, like the given PHP example. React and Django Templating operate the same way of checking right before output.

An added level of security is input validation that forces a user to match specific parameters so random code is less likely to be input

We also have html sanitization. This process runs the entire html document through a function that will scan for unsafe or unwanted html or for what is deemed safe and parse out the opposite then returning the "sanitized" document. PHP has a strip_tags() function for example. This process does not always have the desired result as it can also stip wanted tags and code. The best approach is considered character escaping and focusing directly on where input/data is being out and displayed.

Cross-Origin Resource Sharing (CORS)

Explanation:

"Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. CORS also relies on a mechanism by which browsers make a "preflight" request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request."

From: Mozilla Developer Network: Cross-Origin Resource Sharing

"The W3C CORS specification mandates that for non simple requests, such as requests other than GET or POST or requests that uses credentials, a pre-flight OPTIONS request must be sent in advance to check if the type of request will have a bad impact on the data. The pre-flight request checks the methods and headers allowed by the server, and if credentials are permitted. Based on the result of the OPTIONS request, the browser decides whether the request is allowed or not."

From: OWASP Cross-Origin Resource Sharing

The Origin request header is always sent by the browser in a CORS request and indicates the origin of the request. The Origin header cannot be changed from JavaScript as the browser (the user-agent) blocks its modification; however, relying on this header for Access Control checks is not a good idea as it may be spoofed outside the browser, for example by using a proxy, so you still need to check that application-level protocols are used to protect sensitive data. Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header. From a security testing perspective you should look for insecure configurations as for example using a * wildcard as value of the Access-Control-Allow-Origin header that means all domains are allowed. Another insecure example is when the server returns back the origin header without any additional checks, which can lead to access of sensitive data. Note that the configuration of allowing cross-origin requests is very insecure and is not acceptable in general terms, except in the case of a public API that is intended to be accessible by everyone.

From: OWASP Cross-Origin Resource Sharing

Solutions:

Unless an engineer specifically alters the Access-Control-Allow-Origin setting on the server / response object to allow other sites (or ALL sites via the "*") there is no reason to specifically be concerned with CORS vulnerabilities. The default setting is to let the browser inherently set "same-origin policy" unless it changed. Outside of implicitly changing this setting, the browser will only allow same-origin requests. That being said, the reason we are able to load pictures from another website or fetch data from another api is because the cors setting for that data / server is set to allow CORS / cross origin. In fact. Requests can and are made cross origin all the time. The browser reads the headers in the response object to determine with the response is accepted and allowed to be used / accessed. Additionally embedding of cross origin resources are allowed. It is reading those resources when it comes into question. A list of permitted cross origin resources can be found here: web.dev: Same Origin Policy

What if I want to change the CORS policy on the server?

Example in Node/Express: requiring cors

var express = require('express');
var cors = require('cors');
var app = express();
app.use(cors());
/* your regular routes go here */

Setting Access Control Allow origin to public:

Access-Control-Allow-Origin: *

Restricting to One Origin:

app.use(cors({
origin: 'http://yourapp.com'
}));

Setting to a list of Allowed Origins:

var allowedOrigins = ['http://localhost:3000',
                                'http://yourapp.com'];
app.use(cors({
origin: function(origin, callback){
    // allow requests with no origin
    // (like mobile apps or curl requests)
    if(!origin) return callback(null, true);
    if(allowedOrigins.indexOf(origin) === -1){
    var msg = 'The CORS policy for this site does not ' +
                'allow access from the specified Origin.';
    return callback(new Error(msg), false);
    }
    return callback(null, true);
}
}));

To reiterate: not setting / changing CORS settings is inherently the safest setting for a website and the browser / server are automatically set this way unless specifically changed.

HTTPOnly Cookie (HTTPOC)

Explanation:

Http Cookies: "An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to a user's web browser. The browser may store the cookie and send it back to the same server with later requests. Typically, an HTTP cookie is use to tell if two requests come from the same browser—keeping a user logged in, for example. It remembers stateful information for the stateless HTTP protocol."

From: Mozilla Developer Network: HTTP Cookies

"HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it)."

From: OWASP HttpOnly

Solution:

HttpOnly is a security measure set by the Set-Cookie HTTP Response Header from the server. After examining the network tab in Chrome DevTools for request and response headers as well as the applications tab for any cookies being set, I did not find anything being set by this api. As a result there is not currently a specific cookie vulnerable to scripting attacks for this site. Additionally cookies are only an issue if the ones being set by the server have not been properly secured when setting the cookies in the response header. HttpOnly is just one of those mitigation tactics that can be used to help prevent Cross Site Scripting (XSS). "Cookies are also susceptible to CSRF (Cross-Site Request Forgery), XS-Leaks (Cross-Site Leaks), Network Attacks, and others." App Sec Monkey has an excellent site with explanation on Cookie Related Attacks and mitigation tactics for attacks beyond HttpOnly Cookie settings. HttpOnly settings are easily added by simply adding "HttpOnly" on the response header when setting the cookie.

Example of a secure cookie setup in response headers would be (based on App Sec Monkey):

Set-Cookie: __Host-SessionId=s3cr3t; Secure; HttpOnly; SameSite=Lax; Path=/

Further notes:

"According to Michael Howard, Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks target theft of session cookies. A server could help mitigate this issue by setting the HttpOnly flag on a cookie it creates, indicating the cookie should not be accessible on the client. If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This causes the attack to fail by preventing the malicious (usually XSS) code from sending the data to an attacker’s website."

From: OWASP HttpOnly

Vulnerabilities According to zofixer.com:

Click on the arrow next to the vulnerability to see an explanation and solutions:

Content Security Policy Header Not Set (XSS)

Explanation:

"The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (Cross-site_scripting)."

From Mozilla ContentSecurity Policy

To fix this we can set the content security policy in our application, server side by explicitly setting the policy on the response object that will be returned back to the client after a request is made. OR we can set it explicitly through a <meta> tag.

Solutions(s) Server Side:

For example... when working in NodeJS/ExpressJS we could do this in the server:

res.set("Content-Security-Policy", "default-src 'self'");

This will explicitly set the policy to say that a script can only be accepted from the same origin, which will help prevent cross site scripting. There all multiple other options that can be added on. There are also node packages that can be used specifically for setting the content policy...

const { expressCspHeader, INLINE, NONE, SELF } = require('express-csp-header');

app.use(expressCspHeader({
    directives: {
    'default-src': [SELF],
    'script-src': [SELF, INLINE, 'somehost.com'],
    'style-src': [SELF, 'mystyles.net'],
    'img-src': ['data:', 'images.com'],
    'worker-src': [NONE],
    'block-all-mixed-content': true
    }
}));

Solution(s) Client Side:

And then in the browser we could also do:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';"/>

Further Info: OWASP CheatSheeton Content-Security-Policy

Missing Anti-clickjacking Header

Explanation:

"Clickjacking, also known as a “UI redress attack”, is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page. Thus, the attacker is “hijacking” clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both. Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker."

From: OWASP on Clickjacking:

Solutions:

"Preventing the browser from loading the page in frame using the X-Frame-Options or Content Security Policy (frame-ancestors) HTTP headers. Preventing session cookies from being included when the page is loaded in a frame using the SameSite cookie attribute. Implementing JavaScript code in the page to attempt to prevent it being loaded in a frame (known as a "frame-buster")."

From: OWASP on Clickjacking:

Cross-Domain Misconfiguration (CORS)

Explanation:

From: Mozilla Developer Network: Cross-Origin Resource Sharing

From: OWASP Cross-Origin Resource Sharing

Solutions:

What if I want to change the CORS policy on the server?

Example in Node/Express: requiring cors

var express = require('express');
var cors = require('cors');
var app = express();
app.use(cors());
/* your regular routes go here */

Setting Access Control Allow origin to public:

Access-Control-Allow-Origin: *

Restricting to One Origin:

app.use(cors({
origin: 'http://yourapp.com'
}));

Setting to a list of Allowed Origins:

var allowedOrigins = ['http://localhost:3000',
                                'http://yourapp.com'];
app.use(cors({
origin: function(origin, callback){
    // allow requests with no origin
    // (like mobile apps or curl requests)
    if(!origin) return callback(null, true);
    if(allowedOrigins.indexOf(origin) === -1){
    var msg = 'The CORS policy for this site does not ' +
                'allow access from the specified Origin.';
    return callback(new Error(msg), false);
    }
    return callback(null, true);
}
}));

To reiterate: not setting / changing CORS settings is inherently the safest setting for a website and the browser / server are automatically set this way unless specifically changed.

Absence of Anti-CSRF Tokens

Explanation:

"Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user's web browser to perform an unwanted action on a trusted site when the user is authenticated. A CSRF attack works because browser requests automatically include all cookies including session cookies. Therefore, if the user is authenticated to the site, the site cannot distinguish between legitimate authorized requests and forged authenticated requests. This attack is thwarted when proper Authorization is used, which implies that a challenge-response mechanism is required that verifies the identity and authority of the requester. The impact of a successful CSRF attack is limited to the capabilities exposed by the vulnerable application and privileges of the user. For example, this attack could result in a transfer of funds, changing a password, or making a purchase with the user's credentials. In effect, CSRF attacks are used by an attacker to make a target system perform a function via the victim's browser, without the victim's knowledge, at least until the unauthorized transaction has been committed."

From: Cross-Site Request Forgery Prevention Cheat Sheet

Solutions:

Check if your framework has built-in CSRF protection and use it.
For stateful software use the synchronizer token pattern.
For stateless software use double submit cookies.
Consider SameSite Cookie Attribute for session cookies.
Consider implementing user interaction based protection for highly sensitive operations.
Consider the use of custom request headers.
Consider verifying the origin with standard headers.

Above list from: Cross-Site Request Forgery Prevention Cheat Sheet

Most popular & Recommended: Synchronizer Token Pattern

"CSRF tokens should be generated on the server-side. They can be generated once per user session or for each request. Per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal. However, this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event on the server. In per-session token implementations after the initial generation of a token, the value is stored in the session and is used for each subsequent request until the session expires. When a request is issued by the client, the server-side component must verify the existence and validity of the token in the request compared to the token found in the user session. If the token was not found within the request, or the value provided does not match the value within the user session, then the request should be rejected. Additional actions such as logging the event as a potential CSRF attack in progress should also be considered. For the Synchronised Token Pattern, CSRF tokens should not be transmitted using cookies. The CSRF token can be transmitted to the client as part of a response payload, such as a HTML or JSON response. It can then be transmitted back to the server as a hidden field on a form submission, or via an AJAX request as a custom header value or part of a JSON payload. Make sure that the token is not leaked in the server logs, or in the URL. CSRF tokens in GET requests are potentially leaked at several locations, such as the browser history, log files, network utilities that log the first line of a HTTP request, and Referer headers if the protected site links to an external site."

<form action="/transfer.do" method="post">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZMGYwMGEwOA==">
</form>

Sub Resource Integrity Attribute Missing

Explanation:

"Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match. You use the Subresource Integrity feature by specifying a base64-encoded cryptographic hash of a resource (file) you're telling the browser to fetch, in the value of the integrity attribute of any <script> or <link> element. An integrity value begins with at least one string, with each string including a prefix indicating a particular hash algorithm (currently the allowed prefixes are sha256, sha384, and sha512), followed by a dash, and ending with the actual base64-encoded hash."

From: MDN: Subresource Integrity

Solutions:

An SRI Hash Generator like SRIHash.org can be used to generate a hash for whichever cdn or url you need to secure the integrity of.

Example Script Tag with SRI Hash:

<script src="https://example.com/example-framework.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>

Server Leaks Version Information via “Server” HTTP Response Header Field

Explanation:

"HTTP Headers are a great booster for web security with easy implementation. Proper HTTP response headers can help prevent security vulnerabilities like Cross-Site Scripting, Clickjacking, Information disclosure and more. The Server header describes the software used by the origin server that handled the request — that is, the server that generated the response. Detailed information in this header can expose the server to attackers. Using the information in this header, attackers can find vulnerabilities easier."

Solutions:

"Configure the webserver to stop sending detailed information in the Server header."

"Open the Apache configuration file (httpd.conf or apache2.conf) and add below lines to it."

Code Example in Apache:

ServerTokens Prod
ServerSignature Off

Code Ex. for Nginx:

"Open the Nginx configuration file (nginx.conf) and add below line to either http, server, or location sections. Then restart the server"

server_tokens off;

From: OWASP HTTP Security Response Headers && SmartScanner: Server Version Disclosure

Permissions Policy Header Not Set (XSS) (CORS)

Explanation:

"Permissions Policy, formerly known as Feature Policy, allows the developer to control the browser features available to a page, its iframes, and subresources, by declaring a set of policies for the browser to enforce. These policies are applied to origins provided in a response header origin list. The origin list can contain same-origins and/or cross-origins, and it allows the developer to control first-party and third-party access to browser features. An empty permissions policy is a permissions policy that has an inherited policy which contains "Enabled" for every supported feature, and a declared policy which is an empty map. Set it and disable all the features that your site does not need or allow them only to the authorized domains:"

Solutions:

"Permissions-Policy allows you to control which origins can use which browser features, both in the top-level page and in embedded frames. For every feature controlled by Feature Policy, the feature is only enabled in the current document or frame if its origin matches the allowed list of origins. This means that you can configure your site to never allow the camera or microphone to be activated. This prevents that an injection, for example an XSS, enables the camera, the microphone, or other browser feature."

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), microphone=()

From: Chrome: Permissions Policy && W3C: Permissions Policy

Cross-Domain JavaScript Source File Inclusion (XSS) (CORS)

Explanation:

"Cross-domain JavaScript source file inclusion is a security warning that can affect a web application that runs one or more Javascript files from a third-party domain. If the third-party intentionally or unintentionally holds a malicious content, it can be added and executed on the victim’s web application. This possibility occurs when the external Javascript is not validated. It can lead to the leakage of user data. Sensitive user data can be user’s authentication data (tokens, session IDs, cookies, etc) or personal information (email, home address, phone numbers, social security numbers, etc). When a user sends a request, the script will be updated with the response message. If the response is stored in global variables, everyone can read it. If the sensitive information is included in a JSONP response, the executed function can be overridden to get the sensitive information. This trick can be used for global functions as well. Instead of overriding the executed functions, we may use custom-coded callback functions for global functions."

Solutions:

"It is advised that owners manage web applications by themselves. You can give the privileges to third parties for managing websites, but be careful that they are publicly recognized and trusted."
"Avoid placing sensitive information inside javascript files or JSONP."
"Always try to sanitize user entries that are stored in JSON files." Refer to Cross Site Scripting Solutions (above) for output encoding and escaping user input.
"Enable Content Security Policy (CSP)." And refer to the tab on setting the Content User Oolicy to help minimize XSS.

From: Beagle Security

X-Content-Type-Options Header Missing

Explanation:

"The X-Content-Type-Options response HTTP header is used by the server to indicate to the browsers that the MIME types advertised in the Content-Type headers should be followed and not guessed. This header is used to block browsers' MIME type sniffing, which can transform non-executable MIME types into executable MIME types (MIME Confusion Attacks)."

Solutions:

"Set the Content-Type header correctly throughout the site."

X-Content-Type-Options: nosniff

From: OWASP HTTP Security Response Headers Cheat Sheet