Did you know that according to a a new study by Secure Code Warrior, a surprising 86% of developers do not consider application security as a top priority? This is worrying, as 85% of code bases contain some open source vulnerabilities.
We would like to change that. The vision of GitHub Security Lab is to identify vulnerabilities, expand research, educate, and empower the community to protect the open source software we all depend on. A key step towards this is training developers on the latest security vulnerabilities. This will enable developers to actively identify and report new vulnerabilities in the ecosystem. To that end, let’s look at some of the common weaknesses we’ve recently seen and the tools you can use to combat them.
What types of vulnerabilities exist there?
Vulnerabilities are flaws in your code that, when used by hackers, can lead to personal data leaks, code tampering, or even complete data loss. Keep in mind that the types of vulnerabilities you will encounter will vary depending on the development framework and programming language. However, here are some of the most common types of vulnerabilities you should be aware of:
SQL injection
This is a code injection attack that is triggered when a bad actor adds malicious logic to your SQL statements by user input. The vulnerability stems from failure to disinfect the entrance or improper implementation. Consequences include unauthorized access to data, modification and loss of data, as well as changes in the content and behavior of the application. Some common examples of SQL injection include:
- Modification of an SQL query to return additional results that the user should not have access to (such as payment information).
- UNION attacks that allow data to be retrieved from other tables.
Find other types of SQL injections OWASP website.
Image: xkcd – The exploits of a mother
📺 Learn more about how to protect 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 run on the host system using system privileges. A command injection attack can compromise the application, its data, connected servers, and other infrastructure. Some examples include:
- Inject random commands – when an application receives random system commands directly from other users.
- Random file upload – when an application allows end users to upload files containing random extensions. This makes malicious participants able to inject commands after the uploaded files are added to the web root.
- XML injection of an external object– where bad participants read random files from the server and cause denial-of-service (DoS) attacks.
📺 Learn how to protect your code against injection attacks this video.
Cross-site scripts (XSS)
This is a web injection attack in which malicious scripts are injected into otherwise good quality websites. Due to JavaScript scripts running in the victim’s browser, XSS attacks are able to steal sensitive data such as authentication cookies. This is common on public websites, where attackers can target website visitors by adding their own ads and phishing prompts.
📺 Learn more about how to stop hackers from injecting JavaScript into your webpage this video.
Site Forgery (CSRF) forgery
This attack forces the end user to perform unwanted actions on a web application in which he is currently authenticated. Adverse actions may include the transfer of funds or the alteration of personal information. In general, these attacks take advantage of the trust of the target site for requests initiated by authenticated users, which are in fact initiated elsewhere. An example of a CSRF includes:
- An authenticated user of an online banking website transfers $ 500 to their son’s current account online. However, the bank’s website is vulnerable to the CSRF, so instead of sending money to their son, they send it elsewhere.
📺 Learn how to stop hackers from posing for you through CSRF this video.
For more information on the main types of vulnerabilities, visit Open Web Application Security Project (OWASP) Top Ten.
How GitHub Keeps Your Software Safe – Free
Now, if you’re developing at GitHub, we provide a set of security tools that are primarily for developers to help you find and fix vulnerabilities, and we provide our security tools for free for open source projects. CodeQL-powered GitHub code scanning captures common patterns in your code. It can also work within your download requests, detecting vulnerabilities before they reach your main branch. In addition to protecting your code, CodeQL teaches you what to look out for in the future, as each request contains information about the open vulnerability model, including examples of vulnerable code, secure ways to implement the same code, and external links.
GitHub’s Dependabot alerts you to vulnerabilities in your dependencies and offers updates to secure versions of those dependencies. If you activate Dependabot alerts, you will be automatically notified when a new GitHub-reviewed tip affects the packages you depend on. For supported ecosystems, Dependabot may even open a download request to consolidate updates. Each security board contains information on the vulnerability, including a description, severity, impact, and optional details such as references, corrections, and workarounds.
We also provide a secret scan feature to let you know if third-party service credentials accidentally fall into your source code, and we partner with companies around the world to automatically revoke any secrets they manage to infiltrate, which allows you to rotate them quickly. We now recognize over 69 different secret tokens, but GitHub Advanced Security customers can also customize their own.
To learn more about how to start scanning code with CodeQL, visit our GitHub Docs code scan 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 Secret page for scanning GitHub Docs.
