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 Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
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
  1. DZone
  2. Software Design and Architecture
  3. Security
  4. Are We Doomed to Repeat the Security Mistakes of the Past?

Are We Doomed to Repeat the Security Mistakes of the Past?

If we don't start training developers to use secure coding practices, then the use of vulnerable functions, etc. will only continue.

Kevin Poniatowski user avatar by
Kevin Poniatowski
·
Oct. 19, 17 · Opinion
Like (1)
Save
Tweet
Share
1.89K Views

Join the DZone community and get the full member experience.

Join For Free

The first collegiate programming course I took while working towards a computer science degree was C++. In the first assignment, we were instructed to use two functions that are now known as very insecure: printf() and strcat(). When used incorrectly, these functions allow untrustworthy input to overwrite memory and potentially allow an attacker to perform remote code execution by crafting their malicious input to trick the application into running the attacker's commands. I was writing client-server applications back then, yet with each new architecture, it seems as if we continue to repeat the mistakes of the past.

After my client-server development days were finished, I moved into web application development. One of the more terrifying vulnerabilities that I've stumbled into when creating web applications is the Java Deserialization vulnerability. This is a common issue when an application running on our servers receives serialized XML or JSON. When malicious input of these two types is deserialized, it can overwrite memory and potentially allow an attacker to perform remote code execution. Even though the architecture had changed, untrustworthy input was still allowed to overwrite memory. The error was repeated.

Mobile apps are now prevalent, but by no means immune to the same type of issue. The Objective C language allows for pointer manipulation just like C++ does. This puts the responsibility of memory management on the developers' shoulders and we've seen from the mistakes of the past that memory management can be tricky. For example, Java web application developers turned Objective C developers may have no idea how dangerous the gets() function is despite the warning their development environment gives them when they try to use it. We have a different architecture with incredibly interesting capabilities, but we again have the potential for untrustworthy input overwriting memory when using gets().

The latest and greatest use of technology these days are IoT devices. These are often devices that are typically run on household wifi networks. In the rush to get to market, developers have again made the same mistakes. It's common for IoT developers to use C code to create the software running within these devices. Once again, this puts the responsibility for memory management on the shoulders of these developers and untrustworthy input is again overwriting memory and creating the potential for remote code execution vulnerabilities for attackers to abuse.

Despite there being a defensive coding best practice that mitigates the risk of a buffer overflow occurring in any of these architectures, developers are STILL writing code that allows untrustworthy input to compromise application memory. Validating input and whitelisting that input whenever possible helps defend against this type of vulnerability. But due to a lack of time, budget, and interest, many developers still haven't had the training to educate them about secure coding best practices. Creating software is complicated, but if we want to stop repeating the security mistakes of the past, we have to make training developers a major business priority.

security mobile app Memory (storage engine) dev

Published at DZone with permission of Kevin Poniatowski, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Continuous Development: Building the Thing Right, to Build the Right Thing
  • GitOps: Flux vs Argo CD
  • Using AI and Machine Learning To Create Software
  • ChatGPT — The Google Killer? The Job Taker? Or Just a Fancy Chatbot?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

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

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: