DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

How does AI transform chaos engineering from an experiment into a critical capability? Learn how to effectively operationalize the chaos.

Data quality isn't just a technical issue: It impacts an organization's compliance, operational efficiency, and customer satisfaction.

Are you a front-end or full-stack developer frustrated by front-end distractions? Learn to move forward with tooling and clear boundaries.

Developer Experience: Demand to support engineering teams has risen, and there is a shift from traditional DevOps to workflow improvements.

Related

  • Data Privacy and Security: A Developer's Guide to Handling Sensitive Data With DuckDB
  • Using AUTHID Parameter in Oracle PL/SQL
  • How To Work Effectively With JDBC in Java Scripts
  • Improving Java Code Security

Trending

  • CI/CD Metrics You Should Be Monitoring
  • The Truth About AI and Job Loss
  • OTel Me Why: The Case for OpenTelemetry Beyond the Shine
  • Data Governance Essentials: Policies and Procedures (Part 6)
  1. DZone
  2. Data Engineering
  3. Databases
  4. Java - Four Security Vulnerabilities Related Coding Practices to Avoid

Java - Four Security Vulnerabilities Related Coding Practices to Avoid

By 
Ajitesh Kumar user avatar
Ajitesh Kumar
·
Sep. 19, 14 · Interview
Likes (1)
Comment
Save
Tweet
Share
19.1K Views

Join the DZone community and get the full member experience.

Join For Free
This article represents top 4 security vulnerabilities related coding practice to avoid while you are programming with Java language. Recently, I came across few Java projects where these instances were found. Please feel free to comment/suggest if I missed to mention one or more important points. Also, sorry for the typos.
Following are the key points described later in this article:
  • Executing a dynamically generated SQL statement
  • Directly writing an Http Parameter to Servlet output
  • Creating an SQL PreparedStatement from dynamic string
  • Array is stored directly
Executing a Dynamically Generated SQL Statement

This is most common of all. One can find mention of this vulenrability at several places. As a matter of fact, many developers are also aware of this vulnerability, although this is a different thing they end up making mistakes once in a while. In several DAO classes, the instances such as following code were found which could lead to SQL injection attacks.

StringBuilder query = new StringBuilder();
query.append( "select * from user u where u.name in (" + namesString + ")" );
try {
	Connection connection = getConnection();
    Statement statement = connection.createStatement();
    resultSet = statement.executeQuery(query.toString());
}

Instead of above query, one could as well make use of prepared statement such as that demonstrated in the code below. It not only makes code less vulnerable to SQL injection attacks but also makes it more efficient.

StringBuilder query = new StringBuilder();
query.append( "select * from user u where u.name in (?)" );
try {
	Connection connection = getConnection();
    PreparedStatement statement = connection.prepareCall(query.toString());
    statement.setString( 1, namesString );
    resultSet = statement.execute();
}

Directly writing an Http Parameter to Servlet Output
In Servlet classes, I found instances where the Http request parameter was written as it is, to the output stream, without any validation checks. Following code demonstrate the same:
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
      String content = request.getParameter("some_param");
      // 
      // .... some code goes here
      //
      response.getWriter().print(content);
}

Note that above code does not persist anything. Code like above may lead to what is called reflected (or non-persistent) cross site scripting (XSS) vulnerability. Reflected XSS occur when an attacker injects browser executable code within a single HTTP response. As it goes by definition (being non-persistent), the injected attack does not get stored within the application; it manifests only users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim. You could read greater details on following OWASP page on reflect XSS

Creating an SQL PreparedStatement from Dynamic Query String

What it essentially means is the fact that although PreparedStatement was used, but the query was generated as a string buffer and not in the way recommended for prepared statement (parametrized). If unchecked, tainted data from a user would create a String where SQL injection could make it behave in unexpected and undesirable manner. One should rather make the query statement parametrized and, use the PreparedStatement appropriately. Take a look at following code to identify the vulnerable code.

StringBuilder query = new StringBuilder();
query.append( "select * from user u where u.name in (" + namesString + ")" );
try {
	Connection connection = getConnection();
    PreparedStatement statement = connection.prepareStatement(query.toString());
    resultSet = statement.executeQuery();
}
Array is Stored Directly

Instances of this vulnerability, Array is stored directly, could help the attacker change the objects stored in array outside of program, and the program behave in inconsistent manner as the reference to the array passed to method is held by the caller/invoker. The solution is to make a copy within the object when it gets passed. In this manner, a subsequent modification of the collection won’t affect the array stored within the object. You could read the details on following stackoverflow page. Following code represents the vulnerability:

// Note that values is a String array in the code below.
//
public void setValues(String[] somevalues) {
        this.values = somevalues;
}


Vulnerability Java (programming language) Coding (social sciences) security Database sql Prepared statement Data structure Strings

Published at DZone with permission of Ajitesh Kumar, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Data Privacy and Security: A Developer's Guide to Handling Sensitive Data With DuckDB
  • Using AUTHID Parameter in Oracle PL/SQL
  • How To Work Effectively With JDBC in Java Scripts
  • Improving Java Code Security

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: