Today’s most common security vulnerabilities explained

Did you know that according to a new Secure Code Warrior survey, a surprising 86% of developers do not view application security as a top priority? This is concerning since 85% of codebases contain known open source vulnerabilities.

We’d like to change that. The vision of the GitHub Security Lab is to find vulnerabilities, amplify research, educate, and enable the community to secure the open source software we all depend on. A key step toward this is developer education on the latest security vulnerabilities. This will empower developers to actively find and report new vulnerabilities in the ecosystem. To that end, let’s look at a few of the common weaknesses we’ve recently seen, and the tools you can adopt to combat them.

What types of vulnerabilities exist out there?

Vulnerabilities are flaws in your code that, when exploited by hackers, can lead to private data leakage, code tampering, or even complete data loss. Note that the types of vulnerabilities you’ll encounter will vary depending on the development framework and programming language. That said, here are some of the most common types of vulnerabilities you need to be aware of:

SQL injection

This is a code injection attack that’s triggered when a bad actor adds harmful logic into your SQL statements through user input. The vulnerability stems from not performing input sanitization or performing it incorrectly. Implications include unauthorized data access, modification and data loss, and changes to an application’s content and behavior. Some common SQL injection examples include:

• Modification of an SQL query so that it returns additional results that a user shouldn’t have access to (like payment information).
• UNION attacks, which allow data from other tables to be retrieved.

Find other types of SQL injections on the OWASP website.

^{Image: xkcd – Exploits of a Mom}

📺  Learn more about how to secure your code against SQL injection attacks with this video.

Command injection

This is another code injection attack that occurs when a malicious actor inserts a command into an application that will then be executed in the host system using the system’s privileges. A command injection attack can compromise the application, its data, connected servers, and other infrastructure. Some examples include:

• Arbitrary command injection—where an application receives arbitrary system commands directly from other users.
• Arbitrary file uploads—where an application allows end-users to upload files containing arbitrary extensions. This makes malicious actors able to inject commands once the uploaded files are added to the webroot.
• XML external entity injection—where bad actors read arbitrary files from the server and cause Denial of Service (DoS) attacks.

📺  Learn how to secure your code against injection attacks in this video.

Cross-site scripting (XSS)

This is a web injection attack where malicious scripts are injected into otherwise benign websites. Due to JavaScript scripts running on the victim’s browser, XSS attacks are able to steal sensitive data like authentication cookies. This is common on public websites, where attackers can target the website’s visitors by adding their own ads and phishing prompts.

📺  Learn more about how to stop hackers from injecting JavaScript into your webpage with this video.

Cross-site request forgery (CSRF)

This attack forces the end-user to execute unwanted actions on a web application in which they’re currently authenticated. Unwanted actions might include fund transfers or a change of personal information. Basically, these attacks take advantage of the target site’s trust for requests initiated by authenticated users that in reality are initiated from elsewhere. An example of CSRF includes:

• An authenticated user of an online banking website transfers $500 to their son’s checking account online. However, the bank’s website is vulnerable to CSRF so instead of sending money to their son, they send it elsewhere.

📺  Learn how to stop hackers from impersonating you via CSRF with this video.

For more information on the top types of vulnerabilities, visit The Open Web Application Security Project (OWASP) Top Ten.

How GitHub keeps your software safe—for free

Now, if you’re developing on GitHub, we provide a suite of developer-first security tools to help you find and fix vulnerabilities and we make our security tooling available for free to open source projects. GitHub’s code scanning, powered by CodeQL, catches common patterns in your code. It can also run within your pull requests, detecting vulnerabilities before they reach your main branch. Beyond protecting your code, CodeQL teaches you what to look out for in the future, as each query contains information on the vulnerability pattern detected, including examples of vulnerable code, secure ways to implement the same code, and external references.

GitHub’s Dependabot alerts you to vulnerabilities in your dependencies and suggests updates to safe versions of these dependencies. If you enable Dependabot alerts, you’ll be automatically notified when a new GitHub-reviewed advisory affects the packages you depend on. For supported ecosystems, Dependabot can even open a pull request for you to merge updates. Each security advisory contains information about the vulnerability, including the description, severity, impact, and optional details such as references, fix commits, and workarounds.

We also provide secret scanning functionality to notify you if credentials for third-party services accidentally make it into your source code and partner with companies across the world to automatically invalidate any secrets that do make it through, allowing you to rotate them quickly. We now recognize over 69 different secret tokens, but customers of GitHub Advanced Security can also customize their own.

To learn more about how to get started code scanning with CodeQL, visit our GitHub Docs code scanning page.

To learn more about how to get started with Dependabot, visit our GitHub Docs Dependabot page.

To learn more about how to get started with secret scanning, visit our GitHub Docs secret scanning page.

Written by

Joseph Katsioloudes

@jkcso