Jardine Software

  • Home
  • Solutions
    • Security Testing
    • Security Review
    • Training
      • Fundamentals of Application Security
  • Testimonials
  • Resources
  • Blog
    • .Net Blog
  • About
    • Events
  • DevelopSec

February 6, 2017 by James Jardine

Security Tips for Copy/Paste of Code From the Internet

Developing applications has long involved using code snippets found through textbooks or on the Internet. Rather than re-invent the wheel, it makes sense to identify existing code that helps solve a problem. It may also help speed up the development time.

Years ago, maybe 12, I remember a co-worker that had a SQL Injection vulnerability in his application. The culprit, code copied from someone else. At the time, I explained that once you copy code into your application it is now your responsibility.

Here, 12 years later, I still see this type of occurrence. Using code snippets directly from the web in the application. In many of these cases there may be some form of security weakness. How often do we, as developers, really analyze and understand all the details of the code that we copy?

Here are a few tips when working with external code brought into your application.

Understand what it does

If you were looking for code snippets, you should have a good idea of what the code will do. Better yet, you probably have an understanding of what you think that code will do. How vigorously do you inspect it to make sure that is all it does. Maybe the code performs the specific task you were set out to complete, but what happens if there are other functions you weren’t even looking for. This may not be as much a concern with very small snippets. However, with larger sections of code, it could coverup other functionality. This doesn’t mean that the functionality is intentionally malicious. But undocumented, unintended functionality may open up risk to the application.

Change any passwords or secrets

Depending on the code that you are searching, there may be secrets within it. For example, encryption routines are common for being grabbed off the Internet. To be complete, they contain hard-coded IVs and keys. These should be changed when imported into your projects to something unique. This could also be the case for code that has passwords or other hard-coded values that may provide access to the system.

As I was writing this, I noticed a post about the RadAsyncUpload control regarding the defaults within it. While this is not code copy/pasted from the Internet, it highlights the need to understand the default configurations and that some values should be changed to help provide better protections.

Look for potential vulnerabilities

In addition to the above concerns, the code may have vulnerabilities in it. Imagine a snippet of code used to select data from a SQL database. What if that code passed your tests of accurately pulling the queries, but uses inline SQL and is vulnerable to SQL Injection. The same could happen for code vulnerable to Cross-Site Scripting or not checking proper authorization.

We have to do a better job of performing code reviews on these external snippets, just as we should be doing it on our custom written internal code. Finding snippets of code that perform our needed functionality can be a huge benefit, but we can’t just assume it is production ready. If you are using this type of code, take the time to understand it and review it for potential issues. Don’t stop at just verifying the functionality. Take steps to vet the code just as you would any other code within your application.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

Contact us to discuss more

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Filed Under: Uncategorized Tagged With: application security, appsec, copy, developer, developer training, passwords, paste, secure code, secure defaults, security, security training

January 10, 2017 by James Jardine

When it comes to security, read the instructions

Many of us are fairly technical and have gotten along just fine just clicking through wizards to install new software or devices. For many, it is like building your favorite furniture from IKEA. Who needs instructions? You fight your way through it, making assumptions on what pieces go where and with which hardware. With your furniture, a missed step may lead to some left over parts and the item collapsing at an unfortunate time. With software and devices, a missed step could lead to the loss of sensitive data, loss of money, or even possibly physical harm.

In a perfect world, software and devices would force secure defaults and then require explicit actions to remove that security. We don’t live in that perfect world. This was seen with the recent news about MongoDB databases being exposed on the internet and infected with ransomeware.

In the case of MongoDB, misconfigurations may bind the database port to the public interface, while also allowing anonymous access. This combination can be devastating. Doing a quick search on Shodan you may find there are thousands of misconfigured MondoDB servers exposed on the internet.

Like many other software packages, MongoDB has a security checklist available to help minimize this exposure. The checklist covers important steps, such as enforcing authentication and limiting network exposure. I am seeing more packages that are including security checklists, or security guides that are available. If you are installing something new, take a moment to see if there is a guide availble to properly secure the item.

In addition to the security checklist, the creators of MongoDB have created a post addressing the ransomware attacks that are happening. This link points out a few other items to help secure your MongoDB instance. It also points out that the most popular installer for MongoDB (RPM) limits network access to localhost. This default configuration is critical in helping reduce the exposure of these databases.

As time goes on, I expect we will see more improvements made to these types of products that make them more secure by default. As an organization developing this type of software, or devices, think about how the item is installed and how that reflects security. Starting off more secure and requiring explicit configuration to open make the item available will provide much better protection than it being open by default.

If you are running MongoDB, go back and check the security checklist. Make sure you are not exposing the instance publicly and authentication is enabled. If you are running other software or devices, make sure to know where they are and determine if they are deployed securely. Check to see if a security checklist exists.

We are often in a hurry and just click through the prompts of an installer. However, to provide the proper risk management, we must take the next steps to understand the configurations to protect our assets.


Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you. James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Filed Under: Uncategorized Tagged With: application security, appsec, mongodb, ransomware, secure defaults, secure deployment, security

Newsletter

Sign up to receive email updates regarding current application security topics.

Privacy Policy

Contact Us

Contact us today to see how we can help.
Contact Us

Search

Company Profile

Jardine Software Inc. was founded in 2002. Originally focused on software development, we now focus on helping development teams and … Read More...

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • Facebook
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

Contact Us

Jardine Software Inc.
Email: james@jardinesoftware.com



Privacy Policy

© Copyright 2018-2025 Jardine Software Inc. · All Rights Reserved