Академический Документы
Профессиональный Документы
Культура Документы
Applications
Protecting Against OWASP Top 10 Risks
Chetan Karande
Securing Node Applications
Protecting Against OWASP Top 10 Risks
Chetan Karande
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Securing Node
Applications, the cover image, and related trade dress are trademarks of O’Reilly
Media, Inc.
While the publisher and the author have used good faith efforts to ensure that the
information and instructions contained in this work are accurate, the publisher and
the author disclaim all responsibility for errors or omissions, including without limi‐
tation responsibility for damages resulting from the use of or reliance on this work.
Use of the information and instructions contained in this work is at your own risk. If
any code samples or other technology this work contains or describes is subject to
open source licenses or the intellectual property rights of others, it is your responsi‐
bility to ensure that your use thereof complies with such licenses and/or rights.
978-1-491-95241-2
[LSI]
Table of Contents
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1. Injection Attacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Command Injection 1
Database Injection 5
Conclusion 11
Additional Resources 11
3. Cross-Site Scripting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Attack Mechanics 23
How to Prevent XSS 24
Conclusion 29
Additional Resources 29
iii
5. Security Misconfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Attack Mechanics 36
Preventing Security Misconfiguration 38
Conclusion 42
Additional Resources 42
iv | Table of Contents
Preface
v
• Specific measures to prevent the attack and its implementation
in Node.js.
vi | Preface
This element indicates a warning or caution.
O’Reilly Safari
Safari (formerly Safari Books Online) is a
membership-based training and reference
platform for enterprise, government, educa‐
tors, and individuals.
Preface | vii
Prentice Hall Professional, Addison-Wesley Professional, Microsoft
Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press,
John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks,
Packt, Adobe Press, FT Press, Apress, Manning, New Riders,
McGraw-Hill, Jones & Bartlett, and Course Technology, among oth‐
ers.
For more information, please visit http://oreilly.com/safari.
How to Contact Us
Please address comments and questions concerning this book to the
publisher:
Acknowledgments
I would like to express my gratitude to O’Reilly Media, especially
Allyson MacDonald for providing me the opportunity and inspira‐
tion for writing this report. I would also like to thank the talented
and passionate O’Reilly production team, including Shiny Kalapur‐
akkel and Octal Publishing, Inc., for providing insightful sugges‐
tions and finishing touches to my work.
I would like to thank Bryan Devereaux for his invaluable technical
review and feedback on improving this report. This report could not
have been possible without the patience and strong support of my
wonderful wife, Aparna, and loving kids, Yash and Jui, while I was
devoting hours of family time to completing this report.
viii | Preface
Finally, I would like to thank my mom and dad for being a continu‐
ous stream of love and support in all endeavors of my life.
Preface | ix
CHAPTER 1
Injection Attacks
Command Injection
Using command injection, an attacker can execute arbitrary com‐
mands on the host operating system of a vulnerable application.
This flaw gives enormous opportunities to an attacker, ranging from
reading restricted file contents to installing malware with which the
attacker can take full control of the server and host network.
Attack Mechanics
The child_process core module enables Node developers to invoke
underlying OS commands from the application code. Due to its
name and simplicity of use, the child_process.exec method is
commonly used for making system calls.
1
The exec method takes three arguments: a command in string for‐
mat, an optional options object, and a callback function, as demon‐
strated in Example 1-1.
Input validation
Although execFile or spawn are safer alternatives to exec, these
methods cannot completely prevent command injection. The related
scenarios include developers using these methods to invoke a cus‐
tom script that processes user inputs, or to execute certain OS com‐
mands (such as find, awk, or sed) that allow passing options to
enable file read/write.
Just like other injection attacks, command injection is primarily pos‐
sible due to insufficient input validation. To protect against it, verify
that user-controlled command arguments and command options
are valid.
Command Injection | 3
Using a Whitelist Approach for Input Validation
When writing the validation logic, use a whitelist
approach; that is, define what is permitted and reject
any input that doesn’t fit this definition. Avoid writing
this logic in an opposite manner (blacklist approach),
or, in other words, by comparing input against a set of
known unsafe characters. Attackers can often find a
way to circumvent such filters by being creative with
the input construction.
• ep_imageconvert
• hubot-scripts
• ungit
Database Injection
With a successful database injection, an attacker can execute mali‐
cious commands on a database to steal sensitive data, tamper with
stored data, execute database administration operations, access con‐
tents of files present on the database filesystem, and, in some cases,
issue commands to the host operating system.
Let’s review the injection attacks on both SQL and NoSQL databases.
Database Injection | 5
Example 1-4 illustrates code that dynamically constructs a SQL
query by appending the user-supplied request parameter username.
To exploit this query, an attacker can enter admin' -- as a username,
which ultimately results in executing the SQL query, as shown in
Example 1-5.
The malicious user input eliminated the need for an attacker to sub‐
mit a correct password because the part after -- in a SQL query is
interpreted as a comment, thus skipping the password comparison.
Another, more destructive, variation of SQL injection is possible
with databases that support batch execution of multiple statements
when those statements are followed by a semicolon.
For example, if an attacker enters the string admin'; DELETE FROM
accounts; -- as username, the resultant query is equivalent to two
statements, as shown in Example 1-6.
This query results in removing all user accounts from the database.
An attacker can use a wide variety of malicious inputs for conduct‐
ing injection, such as the following:
connection.end();
Database Injection | 7
Using Stored Procedures Instead of Parameterized Queries
If SQL query construction takes place inside a stored
procedure, generally stored procedures are safe and
have the same effect as parameterized queries. How‐
ever, you need to ensure that stored procedures do not
use unsafe dynamic SQL generation by integrating user
inputs.
Database Injection | 9
Example 1-10. A find query using MongoDB
db.accounts.find({
username: post_username,
password: post_password
});
With this input, the find query in Example 1-10 would compare if
the password in the database is greater than an empty string, which
would return true, resulting in retrieving the admin user’s account
data.
You can achieve the same results by using another comparison oper‐
ator, such as $ne, in the input.
Another mechanism to manifest NoSQL injection is exploiting the
$where operator, which takes a JavaScript function and processes
user inputs within the function. Example 1-12 presents code that is
vulnerable to just such a NoSQL injection:
Conclusion
Although injection flaws are very prevalent, as we reviewed in this
chapter, these security flaws are easy to avoid by applying safe cod‐
ing practices. Using APIs that avoid passing untrusted data directly
to an interpreter, validating user inputs, and applying the principle
of least privileges are the key mechanisms to prevent it.
Additional Resources
Here are some more resources related to injection attacks:
“Testing for SQL Injection”
Injection flaws are difficult to discover via testing. This article
goes over techniques and tools to test for them.
“Stored Procedure Attacks”
This article illustrates SQL injection attacks against stored pro‐
cedures that are often assumed safe against SQL injection by
default.
Conclusion | 11
Server-Side JavaScript Injection
This whitepaper explains server-side JavaScript injection when
using eval in JavaScript code to parse JSON requests.
13
As per a study of 2,260 confirmed breaches in 2015, 63 percent
involved weak, default, or stolen passwords. Thus, safety of user
accounts hinges on protecting these credentials, mainly passwords,
from attackers.
Let’s go through attacks targeting the authentication mechanism and
look at some mitigations.
Password Cracking
Password cracking is equivalent to a burglar picking the lock on the
front door of a house to break in. Password cracking isn’t always as
difficult as one would expect, given the various tools and techniques
that are available to automate the process.
The most guaranteed but time-consuming method to crack a pass‐
word is the brute-force attack. It works by cycling through every
possible combination, ranging from a single character to N charac‐
ters, and trying to log in using it. Tools such as John the Ripper or
Brutus are commonly used to accomplish this.
Because the brute-force technique is slow, a significantly faster ver‐
sion of it is the dictionary attack. Unlike brute-force, a dictionary
attack doesn’t enumerate through every possible character. Instead,
it cycles through words in a particular dictionary or word list to
check if it works as a password. Tools such as Hydra can not only
automate this process, but also morph the characters in words and
try combinations of these words.
The first argument to genSalt, the work factor, decides the cost or
slowness of computing. For example, setting it to 12 means 212
rounds.
To check if a user entered a valid password, simply use the compare
method, as shown in Example 2-2.
app.use(session({
resave: false, // Prevent saving session if unmodified
saveUninitialized: false, // Prevent creating session until
// something to store
secret: '...', // Secret key gets used to sign the cookie
cookie: {}
}));
app.listen(80);
A point worth noting about Example 2-3 is that the cookie is used
just to store the SID, not the session data. Session data stays on the
server side. The default server-side session storage is MemoryStore,
which is not designed for a production use; instead, use a database-
backed session middleware such as connect-mongo, connect-
couchbase, or others.
app.use(session({
resave: false,
saveUninitialized: true,
secret: '...',
cookie: {
httpOnly: true, // Prevent cookie accessed by JavaScript code
secure: true, // Prevent browser sending cookie on unencrypted
// connection
maxAge: 10 * 60 * 1000 // 10 minutes
}
}));
app.listen(80);
Session Fixation
To carry out a session fixation attack, typically an attacker performs
these steps:
Additional Resources
Here are OWASP checklists and cheat sheets related to authentica‐
tion and session management:
Conclusion | 21
CHAPTER 3
Cross-Site Scripting
Attack Mechanics
The key mechanism behind XSS attack is content injection, wherein
an attacker inserts malicious JavaScript content on a web page.
Attackers typically inject just a tiny bit of initial script, which, when
executed, downloads additional required scripts.
Depending on whether the target web application saves the injected
malicious content on the server, there are two primary XSS attack
mechanisms: reflected and stored. Let’s review each of these mecha‐
nisms in more detail.
Reflected XSS
In this mechanism, an attacker provides a link to the victim user
with malicious contents embedded in request parameters. When a
victim user clicks this link, a request goes to the target application
server, where a flaw in the application code results in including the
23
malicious content in the request as-is in the response body. When
the contents of this response load on the user’s browser, the mali‐
cious code executes, causing a successful XSS attack.
For apps that generate page content on the client side, the reflected
XSS can still manifest if the unsafe JavaScript code takes the mali‐
cious content from the attacker-supplied URL and injects it into the
web page.
Reflected XSS is typically a one-to-one attack because an attacker
needs to send the malicious link to each user; hence, it affects only
those users that click it. So, it has relatively less chances of success as
compared to the stored XSS attack, which we’ll review next.
Stored XSS
In a stored XSS attack, the malicious content injected by an attacker
is saved by the application. After that, every user visiting the same
page becomes a victim of the XSS attack. For example, consider the
comments on a blog post. If the comments with malicious content
posted by an attacker are not validated and sanitized before saving
into the database, every time the blog post is read by any user, the
malicious code injected in the comments is executed. Thus, stored
XSS is a one-to-many attack with a greater possibility to cause dam‐
age.
DOM-Based XSS
In both reflected and stored XSS mechanisms, actual
content injection could take place either on a server or
on a user’s browser.
In past years, most security analysts considered stored,
reflected, and DOM-based XSS as three different
attack mechanisms. However, as OWASP clarified in
this article, the DOM-based XSS is not a separate
mechanism, but a particular case of either stored or
reflected XSS attack, wherein payload injection hap‐
pens on a victim user’s browser.
Beyond the JavaScript files, the CSP header can also whitelist sour‐
ces for images, CSS, fonts, and media such as audio and video.
Example 3-1 shows how to add a CSP header to Node apps by using
the helmet module.
Similarly, here are other node modules that had XSS vulnerabilities:
mapbox.js, backbone, dojo, and marked.
Conclusion
The XSS is a prevalent attack. Although output-encoding the
untrusted user data before using it is the best way to protect against
XSS, it is challenging to encode data correctly for all contexts due to
different encoding rules for each context. Also, testing and detecting
XSS flaws is difficult, especially for cases such as stored XSS, for
which feedback is not immediate, or when the contents are gener‐
ated at the client side by using JavaScript libraries. Fortunately, the
wider support for the CSP header in modern browsers provides a
very simple-to-use and robust mechanism for application develop‐
ers to protect against XSS.
Additional Resources
HTML5 Security Cheatsheet
A collection of XSS attack vectors that make use of HTML5 fea‐
tures
Conclusion | 29
CHAPTER 4
Insecure Direct Object References
Attack Mechanics
In this exploit, attackers manipulate the identifier in the request
URL to access other records in the database that do not belong to
them. For example, consider this URL on a vulnerable application:
www.example.com/profile/3032
In this URL, 3032 is an ID of a profile record in the database.
Because it is exposed in the URL and predictable, an attacker can
31
simply change it to some other value and access other users’ restric‐
ted profiles.
Here is an another example of using a URL to retrieve a filesystem
resource:
www.example.com/reports?name=feb2016report.pdf
The name parameter in this URL specifies the exact filename to
retrieve. Attackers can modify this predictable parameter to access
reports for other months, for which they have neither paid nor are
subscribers.
Directory Traversal
The directory traversal is a special case of the insecure direct object
references vulnerability, in which an attacker manipulates the path
exposed in a URL to access directories and files outside of the web
root folder and possibly compromise the entire web server.
To exploit it, an attacker uses absolute or relative path traversal char‐
acters such as /, ../, or its encoded versions %2f, %2e%2e%2f, or %2e
%2e/ to manipulate the path.
Directory Traversal | 33
• In the application code, validate user inputs for presence of path
traversal and corresponding encoded characters.
Conclusion
The internal references to objects such as database IDs or filenames
are often exposed publicly as part of the URL parameters. The tech‐
niques to prevent insecure direct object references primarily focus
on protecting these references as sensitive data and checking access
control at the data-object level.
Additional Resources
• “Testing for Insecure Direct Object References”
• “Meteor Security in the Wild”
35
Figure 5-1. Top 10 most commonly occurring vulnerabilities from the
data sample used for the HPE Cyber Risk Report 2016
Attack Mechanics
There are a variety of attack mechanics to exploit security misconfi‐
guration, each affecting distinct attack surfaces. The subsections that
follow present some examples.
Attack Mechanics | 37
Preventing Security Misconfiguration
The security misconfiguration mitigations fall under the realm of
responsibilities of both app developers and system administrators.
Let’s go over some specific measures to prevent related issues.
Conclusion
The Node platform has its unique advantages and challenges related
to security misconfiguration issues.
The Node frameworks such as Connect or Express are designed to
be minimalistic; that is, unlike some other platforms, a typical Node
server does not come preconfigured with dozens of default features
and switches that developers need to be aware of and tune. Instead,
Node developers assemble the server with only the middleware that
they actually use. This reduces the risk of unknown or default fea‐
tures slipping into production.
On the other hand, the community-driven npm modules add an
extra responsibility on Node developers to vet these dependencies
before using them, and to constantly keep watch on any vulnerabili‐
ties published, keep them up to date, and test apps against them. In
this chapter, we covered possible measures and best practices to pre‐
vent this and other security misconfiguration issues for the Node
apps.
Additional Resources
“Exploiting CORS Misconfiguration” explains a very common
CORS headers misconfiguration which an attacker can exploit to
steal private API keys.
Figure 6-1. Total cost of data breach, based on monetary values and
number of records stolen
43
tion, and user’s trust. In some cases, they result in businesses
actually closing.
This Open Web Application Security Project (OWASP) risk primar‐
ily focuses on mitigating attacks that target web applications in an
attempt to steal sensitive data. In this chapter, we go over related
attack mechanics and ways to protect Node applications against it.
Attack Mechanics
There are three sources from which an attacker can steal the sensi‐
tive data managed by applications: a client such as a browser, a net‐
work, or application servers. Let’s review each.
Cross-site scripting
The most common client-specific attack mechanism is cross-site
scripting (XSS). With XSS, an attacker injects malicious JavaScript
code into a web page, primarily to steal a user’s session identifiers
and then use that information to impersonate the user for the pur‐
poses of gaining access to sensitive data.
The next attack mechanisms require both the victim user and
attacker to access the target application from the same browser on a
shared or public computer.
• URL caching
• Keyboard press caching
• Copy/paste buffer caching
• Application backgrounding
• Logging
• HTML5 data storage
• Browser cookie objects
• Analytics data sent to third parties
Attack Mechanics | 45
Stealing Sensitive Data at Rest
This is the most common mechanism behind large-scale data
breaches. In these attacks, the malicious user gains direct access to
the application’s database server containing the sensitive data. Also,
if application developers are not careful about what goes in the log
files, those log files, and any backups, can be a source of sensitive
data at rest and, consequently, a target for an attacker. The same
applies for any reports generated by an application containing the
sensitive data.
Prevent XSS
By taking measures such as setting the HTTPOnly and Secure
attributes on cookies, input sanitization, and adding Content Secu‐
rity Policy (CSP) headers, we can successfully protect against XSS
attack. Chapter 3 covers these options in more details.
Turning off autocomplete has two effects: the browser stops showing
suggestions based on previously submitted data when a user types in
the form field; and it doesn’t cache field values in the session history.
Thus, after submitting a form, if a user clicks on the browser Back
button, she returns to the form page, but the fields marked as auto
complete="off" remain empty.
You also can use the Node helmet module to set the Cache-Control
header to no-store.
With this header, the browser avoids saving response content in the
cache; instead, it makes a new request to the server each time a user
visits the page or endpoint.
Another most-preferred option to prevent caching is to communi‐
cate via an HTTPS connection. On a secure SSL/TLS network,
browsers assume that all traffic is sensitive; hence, when a user
closes the browser, any content cached in memory is cleaned auto‐
matically. In this case, to enforce static public resources to cache for
a long term, set the Cache-Control response header to public.
Conclusion
A data breach could result from various incidents, such as an acci‐
dental or malicious act of an insider within an organization or even
a business partner; lost or stolen assets such as smartphones, tablets,
laptops, external hard drives, USB keys; or as a result of an external
attack on the web applications that handle sensitive data.
Conclusion | 53
In this chapter, we focused on web-application-specific attacks to
steal sensitive data from a user’s browser, network, or application
servers, and ways to protect against them.
Attack Mechanics
Attackers exploit this vulnerability primarily by manipulating URLs.
For example, consider these URLs provided by an application:
example.com/account/view
example.com/account/remove
Although both require authenticated users, let’s assume that
the /remove endpoint should be available only to the admin user. If
an unauthenticated or an authenticated nonadmin user could access
the /remove endpoint, this is a missing function-level access control
flaw.
55
Preventing Missing Function-Level Access
Control
The first step toward preventing access-control issues is to define
the access-control policy for the application. The access-control pol‐
icy describes security requirements for each functionality so that
developers can implement it in a consistent manner.
In its simplest form, the Node applications can implement access
control by using middleware in a route configuration. The middle‐
ware function acts as a filter that allows you to modify the request
object, write to response, invoke next middleware, or end the
request without continuing the chain. We can add a number of mid‐
dleware functions, each implementing a single specific access-
control rule before invoking the route handler. For example, you can
secure the account/remove endpoint discussed earlier by chaining
isLoggedIn and isAdmin middleware, as illustrated in Example 7-1.
Similarly, the policies file contains ACLs for all controllers in the
application. In the policies file shown in Example 7-3, the isLogge
dIn and isAdmin values refer to simple Express.js middleware func‐
tions, as shown earlier in Example 7-2. By convention, these
middleware should be coded in policies/isLoggedIn.js and policies/
isAdmin.js files, respectively.
For more details on writing policies with sails.js, see the website’s
policies section.
The LoopBack framework also implements the ACL-based authori‐
zation. It provides a command-line tool to make generation of ACL
entries easy. However, unlike sails.js, LoopBack maps ACL rules to
data models and its CRUD methods instead of controller actions.
LoopBack provides a mechanism to resolve any conflicts in ACLs by
applying permission precedence (For example, the DENY rule takes
precedence over ALLOW and DEFAULT), and specificity prece‐
dence (a more specific rule prevails over a more general rule), thus
providing a flexible system that allows specifying the access control
at a granular level.
See the LoopBack documentation for more details on its data access-
control mechanism.
Additional Resources
Here are some additional resources on this topic:
Conclusion | 59
CHAPTER 8
Cross-Site Request Forgery
Attack Mechanics
As the name indicates, an attacker lures a user to visit a cross-site;
that is, an externally hosted malicious web page, which typically
contains a forged HTML form with hidden fields matching the web
page rendered by the target web application.
For example, Example 8-1 shows a malicious web page targeting an
admin user of a vulnerable application. It entices the user to click a
button, which triggers the form submission. Because the server
response goes in a hidden iframe, the victim user doesn’t get any
clue about the transaction.
61
<input type="submit" value="Win !!!"/>
</form>
<iframe name="iframeHidden" width="1" height="1"/>
Next, inside the view template, set the csrfToken value in a hidden
input field named _csrf, as seen in Example 8-4.
...
Conclusion
Thanks to the minimal default feature set of the Express framework,
protection against CSRF is relatively effortless for those applications
that do not need to support plain HTML form submissions and
CORS. All you need to do is not enable middleware such as body‐
parser for URL-encoding and CORS. However, if an application
needs to support these features, including an anti-CSRF token using
the csurf module is an effective way to block the attack.
Additional Resources
The OWASP CSRF prevention cheat sheet
Attack Mechanics
Let’s review how attackers can exploit these vulnerabilities.
67
Exploiting publicly known vulnerabilities often yields success for
attackers. As per a research study done by Verizon, 99 percent of
close to 80,000 security incidents in the year 2014 involved exploit‐
ing vulnerabilities for which CVEs were published at least a year
earlier, some published as far back as 1999. Thus, even decade-old
CVEs often prove useful to attackers and are actively exploited in
the wild.
For Node apps, the applicable CVEs include Node.js vulnerabilities,
as well as advisories found in Node modules.
Scripts in package.json
Before installing a module, check the scripts section in the pack‐
age.json, either from the source code or by running the npm view
<pkgname> scripts command.
Ensure that hooks such as preinstall, install, postinstall, preuninstall,
uninstall, or postuninstall do not invoke any unexpected command
or script. Verify that no commands have a “sudo” prefix.
Node.js
• The nodejs-sec forum and Node.js blog
• The Node wiki with information on breaking changes in relea‐
ses
npm modules
• The Express security updates page
• The Node Security Project advisories page
Maintaining Suites
You can incorporate most of these tools in the build
script and run them as part of the continuous integra‐
tion.
In addition, maintaining a good test suite for applica‐
tion code is extremely useful to ensure functionalities
work as intended after upgrading the dependencies.
Conclusion
The majority of code in a Node application comprises external
dependencies. Because this is inevitable, the security of the applica‐
tion is only as strong as the weakest link in its dependencies.
In this chapter, we covered strategies to vet such external dependen‐
cies, along with tools and resources useful to stay on top of ever-
emerging vulnerabilities and security updates for these
dependencies.
Conclusion | 71
Additional Resources
Here are some additional articles and resources on this topic:
Even though this is the least significant of the Open Web Applica‐
tion Security Project (OWASP) Top 10 risks, unvalidated redirects
and forwards are dangerous, pervasive, and a favorite tool for phish‐
ers.
According to a 2016 research study conducted by Verizon on phish‐
ing, 30 percent of recipients open phishing messages (median time
for the first user to open a message: 1 minute, 40 seconds), and 12
percent click malicious attachments or links (median time for the
first click: 3 minutes, 45 seconds). This reveals the success rate and
execution speed of phishing attacks.
An attacker can abuse this vulnerability to install malware or trick
victim users into disclosing passwords or other sensitive informa‐
tion.
Attack Mechanics
Let’s begin by having a clear understanding of what redirects and
forwards mean:
Redirects
Typically, a redirect involves a server sending an HTTP 302
response to the browser with a different destination URL. On
receiving it, the browser makes a second request to the supplied
destination URL.
73
Forwards
Forwards are transparent to the browser. The server internally
transfers a request to a different resource on the server.
Both redirects and forwards can be unsafe if you’re using user-
supplied input such as a query parameter to decide the destination
without validations. Let’s explore the attack mechanics involving
redirects and forwards.
Attack Mechanics | 75
Incidents Related to Unvalidated Redirects and
Forwards
As a real-world example, an open redirect attack was mounted
against eBay.com. On an external domain, the attacker hosted a
fake login page that looked exactly the same as the legitimate login
page from eBay.com, and redirected users to it. The attack resulted
in leaking numerous eBay.com user credentials.
As another Node.js specific example, the popular serve-static
node module (< 1.7.2) was vulnerable to the open redirect attack.
With this vulnerability, an attacker could append a malicious redi‐
rect destination to a legitimate URL. For example, if a user visits a
URL http//truestedsite.com//www.evilsite.com/%2e%2e, a redirect
happens to URL part after //, that is to www.evilsite.com/%2e%2e
site.</p>
• For internal forwards, allow only relative URLs, and reject abso‐
lute URLs beginning with http, https, or //.
• As part of unvalidated forwards, an attacker typically crafts a
URL that passes the access control check and then forwards the
attacker to a restricted functionality for which the attacker has
no direct access. Therefore, before forwarding to a different des‐
tination resource, verify that the current user is authorized to
access it. See Chapter 7 on missing function-level access control
for more information on related attack mechanics.