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
Please enter at least three characters to search
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

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Buildpacks: An Open-Source Alternative to Chainguard
  • Implementing Row-Level Security
  • Four Essential Tips for Building a Robust REST API in Java
  • Creating Effective Exceptions in Java Code [Video]

Trending

  • Emerging Data Architectures: The Future of Data Management
  • Failure Handling Mechanisms in Microservices and Their Importance
  • Doris: Unifying SQL Dialects for a Seamless Data Query Ecosystem
  • *You* Can Shape Trend Reports: Join DZone's Software Supply Chain Security Research
  1. DZone
  2. Coding
  3. Java
  4. 7 Practical Secure Coding Practices

7 Practical Secure Coding Practices

Software Security is important more than ever. This article provides multiple live secure coding examples one has to apply while developing modern-day software.

By 
Awkash Agrawal user avatar
Awkash Agrawal
·
Apr. 14, 21 · Tutorial
Likes (9)
Comment
Save
Tweet
Share
11.0K Views

Join the DZone community and get the full member experience.

Join For Free

Introduction

Software Security is important more than ever in today's world. If we embed the security in the development phase of the application it not only benefits the overall security adherence but also creates multiple security checkpoints at multiple levels of software. This article provides multiple live secure coding examples one has to apply while developing modern-day software. This article uses Java to show case-live examples; these principles can be adopted with any language of choice.

Application Code Outflow

1. Escape the Input

There are types of attack called injection attacks, where the attacker embeds an execution command/Query impersonating it as normal literal input.

This confuses the execution engine and eventually fools it into giving more info/control to the attacker. To avoid such types of attack, it is advised to escape the user input so that it won’t be interpreted as a command but a literal.  It is advised to escape the data stored in the database as the reverse is also true. Imagine user provide input which is JavaScript to steal the cookies from a browser in some post for example. Now when this is rendered on other users' screens in the browser and if we don’t escape the stored value of the post. JavaScript will be executed and give the attacker more info/control. Below is one such example to escape the input query for the database in Java.

Example:

Potential Risk

Java
 




x


 
1
String query = "SELECT user_id FROM user_data WHERE user_name = '"
2
              + req.getParameter("userID")
3
              + "' and user_password = '" + req.getParameter("pwd") +"'";
4
try {
5
    Statement statement = connection.createStatement( … );
6
    ResultSet results = statement.executeQuery( query );
7
}
8
 
          



Avoids Risks

Java
 




x


 
1
Codec ORACLE_CODEC = new OracleCodec();
2
String query = "SELECT user_id FROM user_data WHERE user_name = '"
3
+ ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID"))
4
+ "' and user_password = '"
5
+ ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd")) +"'";
6
 
          



2. Avoid ID as a Sequence

In some scenarios, an attacker tries to get more information than he/she should be having. For example, if the user of an API is allowing to view users with ID 1-100. Now, if the system used the sequence for ID, the next user will be 101. This attacker can exploit this vulnerability to get information about things that he/she is not entitled to.

Example:

Potential Risk

Java
 




xxxxxxxxxx
1


 
1
String sqlIdentifier = "select TESTING_SEQ.NEXTVAL from dual";
2
PreparedStatement pst = conn.prepareStatement(sqlIdentifier);
3
synchronized( this ) {
4
   ResultSet rs = pst.executeQuery();
5
   if(rs.next())
6
     long myId = rs.getLong(1);
7
 
          



Avoiding Risk

Java
 




xxxxxxxxxx
1


 
1
// This example is for Oracle
2
String sqlIdentifier = "select TESTING_SEQ.NEXTVAL from dual";
3
PreparedStatement pst = conn.prepareStatement(sqlIdentifier);
4
synchronized( this ) {
5
   ResultSet rs = pst.executeQuery();
6
   if(rs.next())
7
     long myId = rs.getLong(1) + UUID.random();
8
 
          



3. Apply Minimalist Approach

In order to reduce the attack surface, the system should adopt a policy of minimal footprint exposure. What essentially it means that system should expose just right no more no less. Let’s take an example here if there is a business requirement where the system needs to respond with 200 HTTP code for the existence of resources, but if we provide a REST API with a get operation. This will increase the attack surface for the attacker. Instead, the system should only have a head method of HTTP protocol that gives info about existence, and not more.

Example:

Potential Risk

Java
 




xxxxxxxxxx
1


 
1
//Get is allowed where we need to just check user exist
2
http://localhost:8080/User/id/1
3
 
          



Avoiding Risk

Java
 




xxxxxxxxxx
1


 
1
http://localhost:8080/User/id/1
2
Head



4. Least Privileges Principle

Let’s say, somehow, one of the users in the customer care department access has been compromised, she has access to order data API. But he/she has been assigned a role of a super admin. In this case, where he/she should be having permission to view, but because of super admin now the attacker can exploit it to launch series of attacks on the system. In order to reduce the attack surface, your API access should only be given based on need and role. There should not be a concept of a super user who can access everything.

5. HTTPS/SSL 2-Way Possibly

Never expose your endpoint/site on HTTP; any ways, most of the browsers now show warning on this, use 2 way SSL for integration end point and HTTPS for sites and end to end encryption.

Data level encryption is another aspect one can start for financial/other sensitive information. As HTTPS will only protect the channel of communication from attackers but if that channel key is compromised it is difficult to protect the data. Thus people suggest using a strong encryption algorithm to encrypt data records as well as traveling over the wire.

6. Do Not Use Insecure or Weak Cryptographic Algorithms

As computing power is increasing, weak keys are no longer secure against the brute force way of breaking things. There are certain cryptographic algorithms not allowed or black-listed by reputed organizations. Below is one such reference from the post where a list of cryptographic algorithms considered insecure.

Examples of Deprecated Cryptographic Algorithms

Ref: https://security.stackexchange.com/questions/78/what-cryptographic-algorithms-are-not-considered-secure

  • SHA-1
  • 1024-bit RSA or DSA
  • 160-bit ECDSA (elliptic curves)
  • 80/112-bit 2TDEA (two-key triple DES)
  • MD5 never was an acceptable algorithm for government use, along with many other older algorithms.

7. Whitelisting of Dynamically Executed Code

If you have code that executes as part of flow coming in from user of API/APP or generated after user input. The system needs to whitelist the commands that we will be executing.

For example, if the system is exposing a service to list the directories on the server, then whitelist ls/dir commands and escape the input flags incoming from the user.

Conclusion

We can divide most of the secure coding practices into 4-5 paradigms including but not limited to encryption, encoding, whitelisting, least privileges, and never trust user input. If a development team adopts these 5 broad paradigms one can substantially reduce the risk of software security being compromised. In this article, we have seen multiple ways we can adopt in our day-to-day life to make the software more secure.

security Coding (social sciences) Java (programming language)

Opinions expressed by DZone contributors are their own.

Related

  • Buildpacks: An Open-Source Alternative to Chainguard
  • Implementing Row-Level Security
  • Four Essential Tips for Building a Robust REST API in Java
  • Creating Effective Exceptions in Java Code [Video]

Partner Resources

×

Comments
Oops! Something Went Wrong

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
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!