Reducing The Risk: A software Engineering Problem

security risk

The best way to solve the software security risk problem is when and where it starts, right at the software creation or as close to the beginning as possible. Solving the problem after the software is written, tested and deployed is like testing and fixing cars after they left the car manufacturing facility. Fortunately, the industry hasalready realized this and started integrating security controls and checks early on in the software development lifecycle.

Shift Left – Developer Centric 

Shift security left is a practice that is intended to find and fix security issues early in the software development lifecycle. The first few iterations of this practice were a Waterfall-ish. For example, OWASP’s version of pushing security left and adding security earlier into the software development lifecycle is OpenSAMM (

OpenSAMM defines 12 security practices divided among 4 business functions. You can see right away how the model makes the assumption that the business functions are nicely segregated from each other. OpenSAMM would work great for organizations that are working using Waterfall methodologies. For Agile development teams, particularly with DevOps practices this would be challenging to implement.

Developer-Centric Solutions

At reshift security we believe that the main reason companies don’t really have a grip over the software security problem, is not the lack of interest by the software developers as many would believe. We believe that the lack of  developer-centric solutions is the main problem. If you look at the software security problem and getting developers to embrace shipping more secure code as a “change”. Developers adopted and promoted several changes before: “API First”, “Cloud”, “Serverless” to list a few. Software developers are a smart breed that solves problems for a living. I see a kiss of death when organizations force the solutions that worked for security audit teams, down onto developers and expect them just to adopt those tools and accept these tools to work for developers.

How Developer-Centric Solutions are Different:
  • Properly shifting security left: shifting security left means integrating security practices early on in the software development lifecycle. According to a research done after Google’s attempt to integrate classic static code analysis tools into their SDLC, a survey has been on the developer’s perception of the issues found depending on when the issues are introduced to them. 74% of the issues flagged at compile time as “real problems,” compared to 21% of those found in checked-in code. 
  • Seamless integration into developer’s workflow: most security tools do integrate into developers workflow. Some integrations are shallow and some other integrations are not. Most security tools offer some integration into the developer’s tools and workflows, perhaps a IDE plugin or some form of integration into the build process. A seamless integration into the development is more than IDE plugins and build integrations. Seamless integration into the developer process is one where the developer almost does not feel they are using a different than what they are normally using but somehow they are writing more secure code. 
  • Developer features: speed, accuracy and usability are features that security tools are not really great at. 

Speed: as discussed before, the speed of software development has gone from months to hours and sometimes minutes. If security is going to prevent the developer from maintaining this speed, it is probably going to be rejected by them.

Accuracy: developers have very low tolerance to false positives. While security engineers look at findings as potential issues, developers look at them as noise. 

Usability: developers appreciate smart and usable tools, because of their craft they come across a lot of tools and usability best practices. 

Ready to get started?

reshift is a light-weight code security tool built for developers to code securely, fix quickly, and deploy fast.

Padding Oracle Primer for Java Developers

padding oracle

The Padding Oracle attack is associated with Modern Symmetric(single key to encrypt/decrypt) Cryptographic systems that use a block cipher. Block ciphers work on encrypting fixed length group of bits called blocks. To enhance security, block ciphers have added modes of operation which support the repeated operation of the cipher across several blocks. Since the original plaintext is never of a fixed length modes of operation employ padding algorithms to ensure all blocks have the same size. The attack relates to the implementation of the Cipher-Block Chaining(CBC) mode of operation and a commonly used PKCS#7 padding scheme and how implementations respond during validation. By iteratively supplying stolen ciphertext concatenated with carefully chosen ciphertext an attacker can work their way towards determining the original data based on receiving padding error or success message.

padding oracle


A Web Application or target vulnerable to Padding Oracle attacks ultimately exposes the confidentiality of their sensitive data. This may lead to account compromise, exposure of sensitive information, and potentially server compromise. A motivated attacker with patience and tools can decrypt sensitive data. Depending on the nature and sensitivity of the data this might lead to account compromise, leakage of sensitive information, and eventually server compromise.

Testing for Padding Oracle in Java

The testing goal for the attack is to determines if the target is vulnerable and not to attempt to decrypt the ciphertext. The broad strokes of this test can be summarized as:

  1. Determine that there is encrypted content traveling to the target.
  2. Determine that the target emits validation messages.
  3. Confirm that those validation messages occur on a variety of errors.

Since establishing that the target is leaking validation information is fundamental to the vulnerability the tester has to pay very close attention to the response of the server. This may go beyond error messages and include timing responses.


  1. Recognize that input is encrypted. This is non trivial as some data in transit may be encoded (base64 for example). This requires potentially decoding the data and careful inspection to see if the data “appears” random.
  2. Recognize blocks. If what you suspect is random data always appears as a combination of blocks (8 or 16) change the first block to all 0s, encode (if necessary), and resend being careful to notice if there are any changes in server behaviour, error messages, or timing. Keep incrementing (and encoding if necessary) the first block while watching server response.
  3. Padding. As this incrementing continues eventually a request will be submitted with the wrong cipher value but the correct number of blocks. This should, if the target is vulnerable, produce a cipher error but not a padding error.

If the target fluctuates in error messages during this sequence then it is vulnerable to a Padding Oracle Attack.

There are also tools available: POET: Padding Oracle Exploit Tool
or PadBuster:Automated Padding Oracle Attacks with PadBuster

Java Fixes

Initialized ciphers of CBC PKCS5Padding as outlined below,

Cipher c = Cipher.getInstance("AES/CBC/PKCS5Padding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);

Must be changed to,

Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
c.init(Cipher.ENCRYPT_MODE, k, iv);
byte[] cipherText = c.doFinal(plainText);


ThreatPost: Padding Oracle Crypto Attack Affect Millions of ASP.NET apps

Security researchers have developed an attack against the mechanism that ASP.NET web applications handle encrypted session cookies. The vulnerability could enable attackers to hijack online sessions.

Want to check your projects for free?


Wikipedia: Padding Oracle Attack
Robert Heaton Blog: The Padding Oracle Attack
Crypto.StackExchange: How Does Padding Oracle Attack Work?
GitHub Luchob Repository: Padding Oracle Attack Demo
OWASP: Testing for Padding Oracle (OTG-CRYPST-002)
InfoSecInstitute: Padding Oracle Attack explanation
Troy Hunt: Fear, uncertainty and the padding oracle exploit in ASP.NET

JSP XSLT Primer for Java Developers

jsp xslt


Extensible Stylesheet Language Transformations (XSLT) is a transformation language that ingests an XML document and transforms that document into another XML document. If an attacker can control the content of the style sheet, he/she would potentially be able to trigger remote code execution (RCE) or server-side path traversal.

Fixes for JSP XSLT

Take for example a simple XSLT transform,

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="">
  <xsl:template match="/technology_companies">
	<xsl:value-of select="system-property('xsl:vendor')"/>

In this example the logic injects value matching /technology_companies, this could be a potential area to inject code. If an attacker were to be able to inject directives, they could discover the XSLT library being used and exploit further, e.g. system-property('xsl:vendor')

A general solution if XSLT is required to be used:

  • Avoid interpreting user defined XSLT documents
  • Do not generate XSLT documents and internal fields from inputs that can be controlled by the user, e.g. company name
  • Based upon the XSLT library in use, review the library’s default settings and disable unsafe functionality that could lead to XML External Entities from being executed

Want to check your projects for free?


WS-Attack: XML Signature – XSLT Code Execution
ContextIS: XSLT Server Side Injection Attacks
OWASP: Path Traversal

JSP JSTL Out Primer for Java Developers

Java Server Pages(JSP) currently can define tag definitions through the Standard Tag Library (JSTL). One of the tag functions is the ability to disable escapeXml which could potentially be dangerous in Cross-Site Scripting attacks. By disabling escapeXml an attacker can manipulate an XML document which is reflected within a client browser and inject HTML and/or Javascript syntax.

Impact of JSP JSTL Out

Exploiting the Standard Tag Library leading to a successful Cross Site Scripting (XSS) attack results in javascript code running in a users browser without their knowledge. That code then reads the session cookie of a logged in session to their bank, work account, or any other account they have a session with. Once in possession of the session cookie, the malicious code then transmits that value to the attacker who can then connect to the site with that session cookie assuming the role of the original user. Now the attacker can do anything as that user.

Fixes for JSP JSTL Out

All data elements rendered within response content must be properly encoded to ensure the data is not interpreted as markup code by the user’s web browser. Depending on where within the response the data is rendered, one of the following encoding methods should be used: HTML: HtmlEncoding should be used to escape all rendered output. For example, script tags are escaped by replacing the < and > characters with < and >. JavaScript: Data rendered within JavaScript code can be encoded into the format \xDD where DD is the hexadecimal value of the ASCII character. This causes the encoded characters to be taken literally by the browser, rather than interpreted as meta characters. URL: Data rendered within a URL should be URLEncoded into the format %DD, where DD is the hexadecimal value of the ASCII character. HTML Attributes: Properly quoted attributes can only be escaped with the corresponding quote. Ensure that the attribute is quoted and that any quotes within the data value are encoded. Most development platforms have a native encoding mechanism that can be leveraged to perform the above encodings. Additionally, there are a number of publicly available APIs that provide encoding functionality.


<%@ taglib prefix="c" uri="" %>
<c:out value="${param.test_param}" escapeXml="false"/>

must be changed to,

<%@ taglib prefix="c" uri="" %>
<c:out value="${param.test_param}"/>

Want to check your projects for free?


CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
Tutorial Point: JSTL fn:escapeXml definition
Oracle: JSTL core Tag out

JSP Spring Eval Primer for Java Developers

JSP Spring Eval
Spring can specify functionality within a Java Server Page(JSP) to inject into the eval tag an expression to be executed at render time. If the expression can be wholly or partially control by user input, an attacker could inject dynamic values to inject code to be executed when the page is rendered on the server.

Impact of JSP Spring Eval

Method invocation and arbitrary code execution can occur within the context of the application allowing for sensitive data exposure, system access and even the risk of the entire server being compromised.

Fixes for JSP Spring Eval

The source of the value(s) should be verified to avoid unfiltered values falling into this risky code evaluation

<%@ taglib prefix="spring" uri="" %>
<spring:eval expression="${param.lang}" var="lang" />
<%@ taglib prefix="spring" uri="" %>
<spring:eval expression="'${param.lang}'=='fr'" var="languageIsFrench" />

must be changed to,

<c:set var="lang" value="${param.lang}"/>
<c:set var="languageIsFrench" value="${param.lang == 'fr'}"/>

Want to check your projects for free?


CWE-94: Improper Control of Generation of Code (‘Code Injection’)
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code (‘Eval Injection’)
Spring Documentation: Class EvalTag

Insecure Data Storage Primer for Java Developers

insecure data storage

Insecure data storage is when files can be identified and contain plain text or encoded credentials. These credentials include usernames, passwords, private encryption keys, and other potentially sensitive data that can be leveraged to obtain unauthorized application access. Depending on the nature of the embedded data, these secrets can be used to obtain access to various application resources, such as back-end database servers and/or administrative functionality.

Fixes for Insecure Data Storage

Remove all instances of plaintext or encoded credentials from within all files. Developers and administrators should always work with the assumption that a malicious attacker is likely to obtain access to application source code (via source code disclosure vulnerability, de-compilation, etc) or other files and scripts used for administration purposes. This assumption is especially critical when considering code that is deployed on externally accessible systems (resources located in web accessible directories, client-side code, etc). Usernames and passwords stored for access to other systems must always be encrypted when stored and should only be decrypted on-the-fly as needed by applications or other systems. Consider encrypting sensitive personally identifiable information, such as social security numbers, to help protect it in the event of unauthorized access to the storage medium.

Want to check your projects for free?


CWE-922: Insecure Storage of Sensitive Information
SE Works: Understanding Insecure Data Storage & How To Approach It
OWASP Mobile Top 10: Exploring Insecure Mobile Data Storage

Insecure Crypto Primer for Java Developers

insecure cryptography

Insecure Cryptography is a general vulnerability in which the encryption algorithm chosen for use cases such as authentication, integrity checks, signature verification is weak and susceptible to attacks. Typical attacks exploit the algorithms collision characteristics, i.e. the ability of the attacker to control/predict what the algorithm produces for two different data inputs. If an attacker was able to identify a collision of two inputs that produce the same output, they would be able to identify the original text.

Impact of Insecure Cryptography

If an attacker can exploit a poorly chosen encryption algorithm, this may allow for an attacker to decrypt the text and violate data confidentiality and/or message integrity.

Fixes for Insecure Cryptography

Reconfigure the service to use a strong encryption algorithm along with key lengths that provide a minimum of 112-bits of effective key strength.

Examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher).

Want to check your projects for free?


CWE-310: Consolidation of Cryptographic Issues
Shattered.IO: How We Broke SHA-1 in Practice
Stack Exchange: What Cryptographic Algorithms Are Not Considered Secure

Information Leakage Primer for Java Developers

Information leakage is a weakness where an application reveals sensitive information such as technical details, environment details, or user-specific data. Sensitive data may be used by an attacker to plan out more refined attacks against the application.

Resources, such as files and directories may be inadvertently exposed through mechanisms such as insecure permissions, or when a program accidentally operates on the wrong object. Alternatively, information is accidentally transmitted over an insecure channel. In addition, information identifying architecture, software, and versions, may provide an attacker with details to focus further attacks. Error messages are also a big source of sensitive information.

Regardless the result is that a resource has been exposed to the an entity that is not authorized to view the data because the software incorrectly maintains control over a resource throughout its lifetime.

Impact of Information Leakage

Customer Names: Amazon exposed customer names and emails in a ‘technical error’

Some Amazon customers received an email from the company telling them their names and emails had been exposed due to a “technical error.” The impact of information leakage issues such as this can range from customers having to reset passwords, change significant elements of their identity (SIN/SSN), to providing an attacker with information about the site and its hosting environment.

Testing for Information Leakage for Java

Testing for information leakage involves:

  • Using a search engine to discover any information about the web application (google dorks, etc)
  • Attempting to fingerprint the web server and web application
  • Access web server meta files for information on file paths
  • fingerprint web application framework via cookies and header
  • Follow all code paths to attempt to generate exception errors
  • unit test extreme error conditions and confirm errors and exception are handled

Examples of Information Leakage

The code below exposes that a given username does not exist in an error message. This enables an attacker to itemize valid and invalid usernames.

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

  PrintWriter out = response.getWriter();

  String username = request.getParameter("username");
  String password = request.getParameter("password");

  if(LoginDao.validateUser(username)) {

    out.print("Sorry - no such username");
    RequestDispatcher rd=request.getRequestDispatcher("index.html");


Java Fixes for Information Leakage

Scrub HTML pages for user information, environment specific information, and technical details that would help attackers learn more about the application, its users, or it’s environments Be careful to not provide sensitive information in error messages and ensure all errors and exceptions are handled in a controlled manner.


Information Leakage Example: UNICEF data leak reveals personal info of 8,000 online learners

The United Nations Children’s Fund (UNICEF) accidentally exposed the personal information of thousands of users of its online learning portal. This was caused by an email which was sent to 20,000 users of the same portal.

Want to check your projects for free?


CWE-200: Information Exposure
CWE-664: Improper Control of a Resource Through its Lifetime
WASC-13: Information Leakage
OWASPTop 10-2017 A3: Sensitive Data Exposure

HTTP Header Injection Primer for Java Developers

Header Injection

Hypertext Transfer Protocol (HTTP) header injection can only occur when user-supplied unsanitized data is copied into a response header. If an attacker can inject a carriage return and line feed (CRLF) into the response header, they can add new HTTP headers and/or any arbitrary content into the application’s response. This can lead to a large number of exploits including HTTP response splitting, session fixation, cross-site scripting, and malicious redirect attacks.

Impact of Header Injection

Header Injection can lead to many exploits by manipulating the header via user input and injecting additional content, control not only the headers of the HTTP but also session and content manipulation within the response. Listed below are some exploits that can occur from header injection.

  • Cross-site scripting attack, which can lead to session hijacking
  • Session fixation attacks by setting new cookies
  • Poisoning the cache of any proxy server and/or browser

Fixes for Header Injection in Java

In general, replacing all occurrences of “\n” might still not be enough. It is best practice to remove both “\n” and “\r” with “” (nothing) when transferring from user input into a response header for CRLF attacks. For HTTP attributes stripping ” “, “”” and “;” can also be used based upon context.

Vulnerable Code:

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String value = req.getParameter("value");
  resp.addHeader("X-Header", value); // Noncompliant
  // ...

Sanitizing User-data:

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String value = req.getParameter("value");

  // Allow only alphanumeric characters
  if (!value.matches("[a-zA-Z0-9]++"))
    throw new IOException();

  resp.addHeader("X-Header", value);
  // ...

Want to check your projects for free?


OWASP: HTTP Response Splitting
CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers (‘HTTP Response Splitting’)

Hard Code Key Primer for Java Developers

Untrusted user input

The use of hard coded cryptographic keys within software greatly increases the possibility that encrypted data may be uncovered. If the code is open source then everyone can read the keys. If the source is stored privately, attackers can possibly still get access to the code or partial snippets of the source code if they have access to the binary, JAR, APK, etc. Hard coded passwords are different than hard-coded cryptographic keys, in that the latter gives a false sense of security. A myth is that simply hashing a hard-coded password before storage will protect information from malicious users. However, many hashes are reversible and many authentication protocols simply request the hash itself, making it no better than passwords.

Impact of Hard Code Key

The impact of hard-coded keys is to by-pass protection and authentication mechanisms or assume identity of another user. By using a hard-coded keys, it increases the likelihood that the account using the key could be compromised by brute-force or other predictive attacks.

Examples of Hard Code Keys for Java

Examples of Hard Code Keys for Java



Vulnerable Code

public boolean VerifyAdmin(String password) {
if (password.equals("68af404b513073584c4b6f22b6c63e6b")) {
    System.out.println("Entering Diagnostic Mode...");
    return true;
System.out.println("Incorrect Password!");
return false;

Solution: Design out hard-coded keys The hard-coded keys should be designed out of the source code by picking an adequate secure storage mechanism to use, whether a database entry, private key store or online key store. Some examples based upon the context:

  • Operating System and Browser Certification/Key Storage
  • Using .pfx and .jks Files (Keystores)
  • Cloud based key management solutions (AWS KMS, Azure Key Vault, Google Cloud KMS, Other independent vendors)

Want to check your projects for free?


Cheat Sheet Series: OWASP Key Management Cheat Sheet