276 BROUGHT TO YOU IN PARTNERSHIP WITH

CONTENTS
öö TOP JAVA VULNERABILITIES

öö TOP 3 WINNERS

öö

Java Application
OWASP TOP 10 VULNERABILITIES

öö APPLICATION
MISCONFIGURATION: EXPOSED
SERVELET

Vulnerabilities: öö APPLICATION
MISCONFIGURATION: EXCESSIVE
PERMISSIONS

What They Are and How to Fix Them

WRITTEN BY RYAN O’LEARY, VICE PRESIDENT, WHITEHAT SECURITY

Half of all enterprise applications written in the last 15 years This Refcard is intended to help Java developers understand the
DZO N E .CO M/ RE FCA RDZ

have been written in Java, making them nearly ubiquitous in the most common Java vulnerabilities and how to fix them early in
enterprise. Unfortunately, this means that Java applications are also the development process.
among the applications hackers most frequently target and attack.
TOP JAVA VULNERABILITIES
Java can be subject to attack based on general vulnerability types,
Below are the most common, prevalent, and significant Java
but there are also some vulnerabilities that are specific to the
vulnerabilities. This list is compiled from the vulnerabilities
Java platform.
found in Java applications as reported in the WhiteHat Security
Application Security Statistics Report for 2017. For each
• Vulnerabilities in standard libraries
vulnerability type, you will find a description of how and where it
• Vulnerabilities introduced by coding errors (e.g., improper occurs, examples of how to fix it, and other general information
construction of a query) about the vulnerability.

Java-specific vulnerabilities include:

• Vulnerabilities in Java libraries

• Vulnerabilities in the Java sandboxing mechanism, which

can allow an attacker to circumvent the restrictions the
security manager has established

Developing secure Java-based applications, free from any of the

above vulnerabilities, is the best way to ensure that applications
are robust and immune to security threats. Incorporating
security into the development workflow helps developers avoid
creating vulnerabilities; correcting a potential vulnerability
during development is exponentially cheaper in both time
and resources than correcting a vulnerability that has been
implemented in production.

1
Stop hiding from
your security officer.
#CoverYourApps with IBM Security’s leading application security solution.
Introduce a strong, security-first mindset into your DevOps culture, without disrupting
agile practices that your organization relies on to produce quality, on-time software.
Start your free trial today!

IBM Application Security on Cloud enhances web and mobile application security, improves application
security program management and strengthens regulatory compliance. Testing web and mobile applications
prior to deployment helps you identify security risks, generate reports and receive fix recommendations.

Access Complimentary Trial Now

IBM Application Security on Cloud

©
Copyright IBM Corporation 2018. IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at “Copyright and trademark
information” at ibm.com/legal/copytrades.html.
 JAVA APPLICATION VULNERABILITIES

AND THE WINNERS ARE…

The most common code vulnerability evident in static application This also suffers a very high serious-to-
security testing (SAST) during the software development process critical ratio, at 81 percent. Both SAST
is Unpatched Libraries. Why? Because modern software is largely and dynamic application security testing
assembled of separate components, and everybody uses open (DAST) detect SQLi criticality equally well,
SQL Injection
source libraries today. These libraries offer readily available but unlike ITLP it cannot be fought with a
(SQLi)
options, but are not very secure. firewall. While SQLi attacks are not easily
mitigated, they are easily preventable,
The same applies to the second most prevalent error: Application
highlighting the importance of
Misconfiguration. Many software components such as
remediating these issues in development.
embeddable debug and QA features worry little about security.
Developers will enable them by default, creating configuration
These are not only the vulnerabilities most
weaknesses that attackers can exploit. These features may
frequently found by SAST, but also one
provide a means to bypass authentication methods and gain
third of these are critical vulnerabilities.
access to sensitive information, perhaps with elevated privileges.
Open source components such as
The answer? Software Composition Analysis (SCA), which is libraries must be fixed in development.
critical when it comes to securing third-party or open source The best method is to include Software
code. SCA looks deeply at the source code of proprietary, open Composition Analysis testing which
source, and commercial code to identify and inventory all examines the security of all source code,
vulnerabilities present. including components.

Critical software errors such as SQL Injection must be fixed Unpatched

Certain vulnerabilities can be mitigated in
Libraries
DZO N E .CO M/ RE FCA RDZ

during development to reduce exposure in production. production, while others like SQLi must
always be remediated in development.
VULNERABILITY RISK RATINGS
A variety of software security testing
Vulnerabilities are rated on five levels of risk – Critical, High,
regimens routinely performed across
Medium, Low, and Note. Critical and high risk vulnerabilities
the SDLC is the best application security
taken together are referred to as “serious” vulnerabilities. There
approach. Platform solutions provide
are three classes of vulnerabilities found to be critical across
this level of visibility and control, leaving
thousands of applications analyzed in development: Insufficient
organizations with enough intelligence to
Transport Layer Protection (ITLP), SQL Injection (SQLi) and
understand how best to fix any software
Unpatched Libraries.
error… for the least cost.

This is the most critical of them, at 94

percent of vulnerabilities. This is a class UNPATCHED LIBRARIES
used to describe errors such as weak Critical Risk: OWASP A9: Stat Report Rank 1
ciphers, certificate misconfiguration or
known vulnerable protocols. While ITLP DESCRIPTION
Unpatched libraries can introduce critical risks to your application.
is highly likely to be found by DAST scans,
Utilizing such a library can introduce vulnerabilities, potentially
it is rarely a critical error because many
Insufficient bypassing security controls that are in place elsewhere. Attackers
organizations are mitigating it via a Web
Transport Layer can take advantage of several well-known information sources,
Application Firewall (WAF).
Protection (ITLP) such as the National Vulnerability Database, US-CERT, CVE
A better fix is for developers to properly Database, and more to identify these potential vulnerabilities and
configure protocols, ciphers and can use them to introduce almost any weakness.
certificates to make them safe. This should
be a “must do” during the development SOLUTION
Be sure to keep components up-to-date and patched. Monitor
process so this error does not make it into
for reported vulnerabilities so that prompt action may be taken.
live applications.
Use a dependency manager (e.g. Maven) to declare a minimum

3 BROUGHT TO YOU IN PARTNERSHIP WITH

 JAVA APPLICATION VULNERABILITIES

version of any dependencies that are declared multiple times or

A9 Using Components with Known Vulnerabilities
are declared transitively (dependency of a dependency). Prevent
systems and services from leaking unnecessary information, A10 Unvalidated Redirects and Forwards
such as version information. If, for some reason, a vulnerable
library cannot be patched or replaced, ensure that compensating APPLICATION MISCONFIGURATION:
controls are in place, such as a properly configured network EXPOSED SERVELET
firewall, IDS/IPS, or application firewall. Critical Risk: OWASP A5: Stat Report Rank 2

Before selecting components, always perform research into DESCRIPTION

known vulnerabilities. Store these findings in a central repository, This Axis application is configured to deploy an administration
include lists of libraries known to be vulnerable, and ensure interface. This interface can be viewed without use of normal
that all development teams have access to this information Authentication/Access restrictions. Malicious users could use this
so that vulnerable libraries can be dealt with immediately, so interface to get access to unintended server functionality. Cases
these components are less likely to be used by accident. Be sure where the application is “internal only” have a reduced likelihood
to consider the actual impact of any vulnerabilities identified. to reflect the need for internal network access. However, exposing
In some cases, the risk may be much higher than normal and unauthenticated administrative functionality even to the
in other cases, the vulnerability may not apply to how the internal network is not secure, and should still be considered a
component will be used. vulnerability with some level of risk.

Establish a company-wide governance policy for selecting, SOLUTION

testing, and approving components for use by development Remove the highlighted snippet from the production web.xml.
teams. When components are approved for use, store them in a Since the neither the AdminServlet and SOAPMonitorService
central repository and share them with other development teams support acceptable authentication schemes, disabling these
DZO N E .CO M/ RE FCA RDZ

throughout the organization. It is best to have a single solution servlets is the only secure option.
rather than several solutions to the same problem. To further
ADDITIONAL RESOURCES
improve consistency and security assurance, version and patch
axis.apache.org/axis/java/security.html
levels should remain consistent throughout the organization.

APPLICATION MISCONFIGURATION:
• Dependency Management tools (e.g. Maven) EXCESSIVE PERMISSIONS
Low Risk: OWASP A5: Stat Report Rank 2
• WhiteHat Sentinel Source provides information on libraries
and frameworks for covered assets. DESCRIPTION
An application may use custom permissions that can then allow
ADDITIONAL RESOURCES
a separate application to access hardware level functionality
maven.apache.org/guides/introduction/introduction- through its API. These separate applications can bypass the
todependency-mechanism.html#Dependency_Management normal prompting procedures for use of sensitive functionalityby
using the API.
OWASP TOP 10 VULNERABILITIES
SOLUTION
A1 Injection
Applications should only request the minimum permissions
A2 Broken Authentication and Session Management (XSS) needed for stated application functionality. Do not request any
unnecessary permissions. Any unused permissions should not be
A3 Cross Site Scripting (XSS)
requested. Future application updates should prompt the user to
A4 Insecure Direct Object References revoke unneeded permissions.

A5 Security Misconfiguration
APPLICATION MISCONFIGURATION: GLOBAL
A6 Sensitive Data Exposure ERROR HANDLING DISABLED
Medium Risk: OWASP A5: Stat Report Rank 2
A7 Missing Function Level Access Control
DESCRIPTION
A8 Cross Site Request Forgery (CSRF)
Disabling a global error handling mechanism increases the risk

4 BROUGHT TO YOU IN PARTNERSHIP WITH

 JAVA APPLICATION VULNERABILITIES

that verbose implementation details will be revealed to attackers application much easier to audit, since it eliminates the need
through a stack trace. to perform time consuming (and expensive) data flow analysis.
It is important to note that there are different output contexts
SOLUTION
which encoding functionality must handle, including HTML, HTML
To minimize the risk of disclosing sensitive implementation
attributes, URLs, CSS, and JavaScript. A single encoding approach
details through error messages, ensure the application
will not necessarily mitigate XSS in every context.
deployment descriptor declares an error-page declaration that
catches all uncaught exceptions thrown by the application. If output encoding isn’t practicable, the next most effective
approach is to carefully filter all input data against a white-list of
EXAMPLES
allowed characters. This approach does have the advantage that
The web.xml should define error handling elements such as:
it can be performed externally without modifying application
<error-page> source code. Data retrieved from third-parties or shared with
<error-code>500</error-code>
<location>/path/to/default_500.jsp</location>
other applications should be filtered along with user input
</error-page> data. The white-list should only include characters which may
<error-page> be a legitimate part of user input. The following characters
<exception-type>java.io.IOException</exception-type>
are especially useful for conducting XSS attacks and should
<location>/path/to/default_exception_handler.jsp</
location> be considered in any encoding or filtering scheme: < > “ ‘ ; & ?
</error-page> One or more of these characters, such as the single quote, may
be required by the application. If it is impracticable to remove
CROSS-SITE SCRIPTING (“XSS”) one or more dangerous characters as part of an input filtering
High Risk: OWASP A3: Stat Report Rank 3
scheme, they must be carefully handled. Such characters could,
for example, be encoded on input, and stored encoded in the
DESCRIPTION
database. Ideally, the application should perform careful input
DZO N E .CO M/ RE FCA RDZ

Cross-site scripting (sometimes referred to as “XSS”)

vulnerabilities occur when an attacker embeds malicious validation and use output encoding to guard against XSS and
clientside script or HTML in a form or query variables submitted other injection attacks.
to a site via a web interface, sending the malicious content
ADDITIONAL RESOURCES
to an end-user. If this content is submitted by one user (the http://www.owasp.org/index.php/Cross_Site_Scripting
attacker), stored in the database, and subsequently rendered
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_
to a different user (the victim), a Persisted Cross Site Scripting
Prevention_Cheat_Sheet
Attack occurs. A variation of this attack, known as Reflected Cross
Site Scripting, occurs when an attacker entices a victim into
CRYPTOGRAPHY: IMPROPER PSEUDO-RANDOM
submitting the tainted data themselves, via an email or a link on NUMBER GENERATOR USAGE
an attackercontrolle website. Medium Risk: OWASP NA: Stat Report Rank 4

An attacker can use XSS to send malicious script or other content DESCRIPTION
to an unsuspecting user. Neither the end user nor their browser Insufficient randomness results when software generates
knows that the content was not actually generated by the trusted predictable values when unpredictability is required. When a
website. The malicious script can access any cookies, session security mechanism relies on random, unpredictable values to
tokens, or other sensitive information retained by the browser restrict access to a sensitive resource, such as an initialization
and used by the site. These scripts can even rewrite the content of vector (IV), a seed for generating a cryptographic key, or a
the HTML page. This can result in phishing attacks, identity theft, session ID, then use of insufficiently random numbers may allow
website defacement, denial-of-service, and other attacks. an attacker to access the resource by guessing the value. The
potential consequences of using insufficiently random numbers
SOLUTION
are data theft or modification, account or system compromise,
The most reliable means of thwarting most types of XSS attacks
and loss of accountability – i.e., non-repudation.
is to HTML-encode or URL-encode all output data, regardless of
the data’s source. This ensures that tainted data can’t affect the SOLUTION
output from any source, including user input and information When using random numbers in a security context, use
shared with other applications or originating from third-party cryptographically secure pseudo-random number generators
sources. Consistently encoding all output data also makes the (CSPRNG).

5 BROUGHT TO YOU IN PARTNERSHIP WITH

 JAVA APPLICATION VULNERABILITIES

EXAMPLES Java application, and this varies depending on the container. Here
is one example of debug_mode disabled for the jsp servlet:
byte[] randomBytes = new byte[8];
SecureRandom random = new SecureRandom();
<servlet>
random.nextBytes(randomBytes);
<servlet-name>jsp</servlet-name>
<servlet-class>oracle.jsp.runtimev2.JspServlet</servletclass>

APPLICATION MISCONFIGURATION: DEBUG <init-param>

<param-name>debug_mode</param-name>
Medium Risk: OWASP A5: Stat Report Rank 5
<param-value>false</param-value>
</init-param>
DESCRIPTION
Application errors commonly occur during normal operation,
Since developers may have implemented their own custom debug
particularly when the application is misused, even unintentionally.
mode, be sure to inspect configuration files and search the code
If debugging is enabled, then, when occurs occur, the application
base for things like:
may provide inside information to end-users who should not
have access to it and who may use it to attack the application. DEBUG MODE
Error messages displayed to an end user could include server debug = true
debug = 1
information, a detailed exception message, a stack trace, or even
debug
the actual source code of the page where the error occurred. This
information could be used to help formulate an attack.
DISCLOSURE: CLEARTEXT PASSWORD
Medium Risk: OWASP A2: Stat Report Rank 6
If the application provides a switch to enable debug mode in
production, attackers could guess or learn of this parameter and DESCRIPTION
take advantage of any additional information the application may If an application contains one or more hardcoded passwords
provide. Custom debug mode implementations have even been within the source code, an attacker with access to the source
DZO N E .CO M/ RE FCA RDZ

observed to bypass authentication or assign administratorlevel code or compiled binaries can extract the credentials in an
permissions for testing purposes. attempt to access the corresponding services. Obscuring
passwords using encoding, such as Base-64, is not sufficient.
SOLUTION Storing passwords in cleartext (e.g. in an application’s properties
Debug mode should be disabled in production. In addition to any
or configuration file) can result in account or system compromise.
debug mode provided by the programming language, developers
This exposes the password to any personnel with access to the
may implement their own custom debug mode. Custom debug
application’s configuration files – developers, architects, testers,
options should be stored in application configuration files rather
auditors, and development managers. Because it is possible that
than source code, but it may be necessary to search the code base
others may have access to a user’s password, the owner of an
to verify there are no hidden debug options.
account can no longer be presumed to be the only person able to

Production code should normally not be capable of entering login to the account.

debug mode or producing debug messages. However, if this

SOLUTION
capability is necessary, debug mode should be triggered by
System passwords should be encrypted, or the configuration
editing a file or configuration option on the server. In particular,
file they are contained within should be encrypted, whenever
debug should not be enabled by an option in the application itself.
possible. Credentials should be encrypted with a key and stored
For example, it should not be possible to pass in a URL parameter
on disk in a non-web-accessible directory, read-only accessible
to trigger debug mode, such as the following: www.website.
to the user running the web application (webserver). The key
com?debug=true. Regardless how obscure the parameter may be,
should be stored in a separate non-web-accessible location that
it is never a secure option.
is also read-only to the user running the web application. The

Frameworks and components used by the application may have application can then read the key (from a known static location),

their own debug options as well. It is important that debug read the encrypted credentials, decode, and use them. The

options are disabled throughout the application before the encryption key should be rotated on a 30- to 90-day basis. User

application is deployed. passwords should be stored using a strong one-way hashing

algorithm, such as SHA-256. A cryptographic salt should be added
EXAMPLES to each password before it is hashed. The salt should be at least,
There are many instances were a Debug mode may exist within a 64-bits in length and should be random or unique to each user.

6 BROUGHT TO YOU IN PARTNERSHIP WITH

 JAVA APPLICATION VULNERABILITIES

EXAMPLES read data from a socket or file; however, readLine() reads data
There are many approaches and libraries available for encrypting/ until it encounters a newline or carriage return character in the
ecrypting data in Java. Many common approaches are less than data. If neither of these characters are found, readLine() will
secure. Java developers often encode system passwords in continue reading data indefinitely. If an attacker has any control
Base-64 or encrypt them with DES - neither approach is secure, over the source being read, he or she can inject data that does not
especially encoding. have these characters and cause a denial of service on the system.
Even if the number of lines to be read is limited, an attacker
The following code can be used to encrypt/decrypt using a secure
can supply a large file with no newline characters and cause an
algorithm, AES:
OutOfMemoryError exception.

public static String encrypt(String value, File keyFile)

SOLUTION
throws GeneralSecurityException, IOException {
OWASP’s Enterprise Security API (owasp.org/index.php/
if (!keyFile.exists()) {
Category:OWASP_Enterprise_Security_API) provides a safer
KeyGenerator keyGen = KeyGenerator.
getInstance(CryptoUtils.AES); alternative to readLine() called SafeReadLine(). This method reads
keyGen.init(128); from an input stream until end-of-line or the maximum number of
SecretKey sk = keyGen.generateKey(); characters is reached, effectively mitigating this risk.
FileWriter fw = new FileWriter(keyFile);
fw.write(byteArrayToHexString(sk.getEncoded())); Another solution is to override both BufferedReader and the
fw.flush(); readLine() method and implement a limit for the maximum
fw.close(); number of characters that can be read. In the absence of a more
}
secure method, avoid taking input from the client whenever
SecretKeySpec sks = getSecretKeySpec(keyFile);
possible and ensure data being read is trusted.
Cipher cipher = Cipher.getInstance(CryptoUtils.AES);
cipher.init(Cipher.ENCRYPT_MODE, sks, cipher.
DZO N E .CO M/ RE FCA RDZ

EXAMPLES
getParameters());
OWASP ESAPI’s safeReadLine() can be used to safely read
byte[] encrypted = cipher.doFinal(value.getBytes());
return byteArrayToHexString(encrypted);
untrusted data as follows.
}
ByteArrayInputStream s = new
ByteArrayInputStream(“testinput”.getBytes());
INJECTION: UNKNOWN INTERPRETER IValidator instance = ESAPI.validator();
Medium Risk: OWASP A5: Stat Report Rank 7 try {
String u = instance.safeReadLine(s, 20);
} catch (ValidationException e) {
DESCRIPTION // Handle exception
The application makes use of untrusted data in conjunction }
with the creation and or use of an interpreter. Untrusted data
is retrieved from the attacker and utilized as an argument to a URL REDIRECTOR ABUSE
dangerous interpreter access method. Failure to properly validate Medium Risk: OWASP A10: Stat Report Rank 9
or encode data utilized by an interpreter increases the risk of
injection attacks. Such injection typically results in the attacker’s DESCRIPTION
ability to execute arbitrary code in the context of the program Applications frequently redirect users to other pages using stored
consuming the interpreter results. URLs. Sometimes the target page is specified in an untrusted
parameter, allowing attackers to choose the destination page or
SOLUTION location. Such redirects may improperly leverage the trust the
Define and enforce a strict set of criteria defining what the user has in the ulnerable website.
application will accept as valid input, and contextually encode all
untrusted data passed to the interpreter prior to execution. SOLUTION
If untrusted data becomes part of a redirect URL, ensure that the
supplied value has been properly validated and was part of a
DENIAL OF SERVICE (DOS): READLINE
legal and authorized request from the user. It is recommended
Medium Risk: OWASP NA: Stat Report Rank 8
that legal redirect destinations be driven by a “destination id”
DESCRIPTION that is mapped to the actual redirect destination server-side,
The java.io.BufferedReader readLine() method can be used to rather than the actual URL or portion of the URL originating from

7 BROUGHT TO YOU IN PARTNERSHIP WITH

 JAVA APPLICATION VULNERABILITIES

the user request. Lookup-maps or access controls tables are best MISSING ACCESS STRATEGY
for this purpose. High Risk: OWASP A5: Stat Report Rank 13

INSUFFICIENT SESSION EXPIRATION DESCRIPTION

Medium Risk: OWASP A2: Stat Report Rank 10 This application is not utilizing an access control strategy for one
or more components. Failure to utilize access control can lead to
DESCRIPTION exposure of sensitive functionality to unintended users. Malicious
PCI Data Security Standards Version 3, Section 8.1.8 specifies a
users seek out this type of functionality to cause harm to users
maximum session timeout of 15 minutes for critical components
of the application, or the application itself. In Websphere, if you
of an application: “If a session has been idle for more than 15
enable servlets by class name, then this is performing the same
minutes, require the user to re-authenticate to re-activate then
act as Android in that it allows you to invoke by the class. If the
terminal or session.”
following snippet exists or the variable is not declared, this allows

User sessions with long or no inactivity timeouts may help you to invoke servlets without any permissions:

attackers replay attacks or hijack sessions. Social engineering

enable-serving-servlets-by-class-name value=”true”
attacks are also more likely to succeed with a longer time-out. An
attacker has a greater opportunity to gain physical access to a SOLUTION
user’s machine if a user does not close the application. Utilize an access control strategy for all components of the
application where sensitive functionality may reside. Prevent
If the session timeout is not specified in a web application’s
servlets from serving by classname by adding the following line:
configuration, the default value will be used, which is often 24,
30, or 60 minutes, depending on the web server, version, and enable-serving-servlets-by-class-name value=”false”
its configuration.
DZO N E .CO M/ RE FCA RDZ

INSUFFICIENT TRANSPORT LAYER PROTECTION

SOLUTION
DESCRIPTION
In general, idle user sessions should timeout within 15-20 minutes,
Applications frequently fail to encrypt network traffic when it
or less for sensitive applications. Consider disabling “sliding
is necessary to protect sensitive communications. Encryption
expiration” if the configuration option exists. If it is necessary to
(usually TLS) must be used for all authenticated connections,
enable this option, consider implementing a hard session timeout
especially Internet-accessible web pages. Backend connections
in addition to the sliding timeout. When sessions timeout, the
should be encrypted as well. Otherwise, the application will
application should invalidate the session, removing session data
expose an authentication or session token to malicious actors
as well as any cookies and authentication tokens.
on the same network as the application host. These backend
EXAMPLE connections may represent a lower likelihood of exploitation
The session timeout can be configured at the server-level in the than a connection over the external internet; however, in the
default web.xml or for each web application individually. The case of exploitation they can result in compromise of user
following code should be included in the application’s web.xml file: accounts or worse.

<session-config> Encryption should be used whenever sensitive data, such as

<session-timeout>15</session-timeout>
credit card or health information, is transmitted. Applications that
</session-config>
fall back to plaintext or are otherwise forced out of an encrypting
If WebLogic is being used, the session timeout should also be mode can be abused by attackers.
specified in the weblogic.xml file. The following code sets the
timeout to 15 minutes: SOLUTION
Ensure the application has a security constraint that defines a
<?xml version=”1.0” encoding=”ISO-8859-1”?> confidentiality and integrity-based secure transport guarantee.
<weblogic-web-app xmlns=”http://www.bea.com/ns/ This will ensure that all data is sent in a manner that guarantees
weblogic/90”>
it cannot be observed or changed during transmission. If TLS
<session-descriptor>
<timeout-secs>900</timeout-secs> must be terminated at a load balancer, web application firewall,
</session-descriptor> or other inline host, it should re-encrypt the data in transit to the
</weblogic-web-app>
target host(s).

8 BROUGHT TO YOU IN PARTNERSHIP WITH

 JAVA APPLICATION VULNERABILITIES

CONCLUSION vulnerabilities can lead to terrible – but avoidable – attacks.

All organizations must implement application security Adoption of secure DevOps, or DevSecOps, is imperative for true
procedures early in their SDLC. It has been proven to be faster security in the age of digital business.
and less expensive to catch and fix flaws earlier rather than
later. Routine security testing in development makes resulting
production applications stronger. Organizations that integrate
multiple kinds of testing regimens (e.g., DAST, SAST, mobile, etc.)
directly with their SDLC see the best results. Today’s application
security platforms extend visibility and control even further with
Software Composition Analysis, API testing, developer training,
and other services.

From WannaCry to the September 2017 Equifax breach, we are

reminded almost daily that that the failure to address application

Written by Ryan O'Leary, Vice President, WhiteHat Security

Ryan is Vice President of the Threat Research Center at WhiteHat Security, the specialized team of web application security
experts. Ryan joined WhiteHat Security as an ethical hacker in 2007 and has since developed a breadth of experience finding
and exploiting web application vulnerabilities and configuring automated tools for testing. Ryan manages a team of over 150
security engineers, and is also responsible for overseeing the delivery of the WhiteHat Sentinel Application Security Platform,
which services over 10,000 customer websites. Under Ryan’s leadership, the team has built a one-of-a-kind database that
combines details of many millions of million vulnerability patterns with proprietary algorithms to assess the threat level.
DZO N E .CO M/ RE FCA RDZ

As one of the world’s leading experts on application security, Ryan is frequently turned to by the media for commentary on
some of the most pressing cyber security issues.

DZone, Inc.
DZone communities deliver over 6 million pages each 150 Preston Executive Dr. Cary, NC 27513
month to more than 3.3 million software developers, 888.678.0399 919.678.0300
architects and decision makers. DZone offers something
Copyright © 2018 DZone, Inc. All rights reserved. No part of this publication
for everyone, including news, tutorials, cheat sheets,
may be reproduced, stored in a retrieval system, or transmitted, in any form
research guides, feature articles, source code and more. or by means electronic, mechanical, photocopying, or otherwise, without
"DZone is a developer’s dream," says PC Magazine. prior written permission of the publisher.

9 BROUGHT TO YOU IN PARTNERSHIP WITH