As hackers start attacking our applications more and more, it is imperative that organizations begin treating security testing with the same enthusiasm they give to quality testing. Just like if there are major functionality issues or a feature isn’t working the product doesn’t ship – the same attitude needs to go for deploying with major application security vulnerabilities.
This requires a shift in the company culture that makes security seen as everyone’s responsibility – not just the security teams. One of the best ways to help facilitate that change is to spread security awareness among the different stakeholders, educating them in how to take responsibility for security in their jobs.
For CISOs, it may be discussions around the ROI of security testing; for non-technical employees that may include security awareness courses on how to avoid phishing campaigns. For developers, that education needs to be a bit more in depth – developers, after all, are the ones writing the code that needs to be better secured.
Any security stakeholder should understand, at the very least, basic security concepts and what kinds of damages they could introduce if not properly mitigated before deployment. And while the executive board has more of a business imperative to understanding security vulnerabilities, developers have a real hand at making high quality, secure applications for your organization and its customers.
Developers need to know about the OWASP Top 10 and how to avoid the application security vulnerabilities defined on the list. If a security awareness program isn’t in place in your organization, teach yourself when you can – it will pay off in your future. Learning to look at code as if it were being used in ways you don’t necessarily intend it to be used is a great way to educate yourself about how hackers infiltrate apps – and how you can protect against it. If you’re not already practicing your hacking skills, now is a great time to start.
Below are the three most common application security vulnerabilities, and if you’re working on any type of application, be it mobile, web, or IoT, you need to understand the underlying causes of these vulnerabilities – and how to avoid them in your own code. In this post we discuss three injection attacks in depth and what the attackers are trying to accomplish by using each technique. To understand how to avoid them, make sure to check out our new Vulnerability Knowledgebase.
Though one of the oldest attacks, SQL injections remain the most common application security vulnerability to pop-up. Found on many sites using PHP and ASP, SQL injections run rampant on WordPress, yet could also be found on any site or web app using SQL-based databases – which makes up quite a big chunk of the web. Just recently, VTech announced a major breach wherein the information of 4.8 million people, many of which were children, was leaked, including names, emails, home addresses and more – but there are many more SQLi fails than we could ever know (but if you’re interested, the SQL injection Hall of Fame is a great place to read what could happen with an SQLi fail).
In general, code injection attacks allow attackers to modify a statement of command in the database or backend, through an un-sanitized user input. This is due to the mixing of different types of data, usually control statements or instructions along with actual data separated by, for example, a comma. For the injection to take place, the web application or website would have to allow user input within a query. When those statements are not properly sanitized, data that comes from untrusted and possibly malicious sources can be submitted – and that’s where the trouble begins.
SQL injections, specifically, occur when the SQL statements accepted by the web application are not sanitized, opening the backend database up to deletion and/or modification and potential attack. Because web application forms like login details, payment details, etc. require access to the SQL database, any form or area which accepts input could be subject to such an attack.
There are two types of SQL Injections:
The attacker tries to get details on the syntax required to build an attack against the database by performing operations that result in errors. The attacker takes the information gleaned from the error messages to build an attack using the correct syntax.
Here, the attacker can’t get enough information from the error messages to form an attack, so they examine how the database responds to various queries, trying their luck to see if they can get a different kind of response showing where the applications’ vulnerability (or vulnerabilities) lies. If they succeed, they’ve found a crack into the database, and can design an attack built off the crack.
The aim of leveraging SQL injections is usually to gain access to the sensitive data included within the web application’s database, especially Personally Identifiable Information (PII) along with other customer data (especially the kind with credit card numbers). The extent of damage an SQL injection can impose naturally depends on what data is stored in the database, along with the permissions the application requires and if they can be elevated to gain higher access. If administrative access can be gained by an attacker, your database can be stolen or just plain deleted, and could even be elevated to get at your backups, as well. In worst case scenarios, the attacker can also gain access to the database server, opening an organization up to way bigger issues than a lost database.
Learn how to detect and mitigate SQL injections here.
As we discussed above, web application injections occur when a malicious user enters in data that wasn’t properly sanitized before being accepted by the app. How applications accept user input and user data is one of the most vital aspects of application security, you will come to find. Injections, number one on the OWASP Top 10, along with their causes just aren’t well understood. And it is that misunderstanding that has wreaked havoc in web applications and the organizations that own them. LDAP injections, though easily mitigated, may be the least understood injection attack.
Per Wikipedia, LDAP, or the Lightweight Directory Access Protocol, is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory services over an Internet Protocol (IP) network. LDAP directory services, based on a client/server model, are applications that our email systems, network printers, encryption certificates and more use to get information from the local server.
Most email programs have them, so if you’ve ever looked up your colleagues email, you’ve used LDAP. Likewise, if you’re developing mail apps or similar, you need to understand how LDAP injection occurs. As more and more sensitive and critical data is stored within corporate databases, LDAP injection payloads will increase in both numbers and value.
The trouble that leads to LDAP injection is due to weaknesses in the code that allow the manipulation of search filters, which could offer up access to the database on which the LDAP tree is held. Much like SQL injections, the idea behind LDAP injections are to manipulate parameters in the search function. If not sanitized before being sent to the server, the attacker can input a malicious query or code.
If successful, the attacker can alter the statement to run the process with the same permissions granted to the server that executed the command. And that’s where things usually turn sour.
Using arbitrary commands, an attacker could modify, delete, or add to an LDAP tree, much like SQL injections. Even more critical damages arise from the use of single sign-on(SSO) processes that use one password to login to the LDAP directory, along with other critical business applications, including your CRM, HR management systems, shopping cart apps, accounting software, etc.
Learn how to detect and mitigate LDAP Injections here.
Yet another type of injection attack, Cross-Site Scripting, or XSS, is the most prevalent attack on the web and a bit different from other forms of injection attacks, and was given it’s own spot on the OWASP Top 10. It differs from other injection attacks because it’s targeting users of the web application, as opposed to a database or organization at large.
Stored XSS attacks, sometimes referred to as Persistent XSS, occur when the malici
ous code injected by the attacker is kept permanently wherever it was injected, continually injecting every visitor to the site. From there, the opportunities are endless.
Depending on the kind of application used in an XSS attack, damages posed by XSS attacks can range from harmless and annoying (like the Samy worm) to more severe situations, such as back in 2013 when an attack on Yahoo email allowed attacker to hijack accounts and use them to deliver spam. Stored XSS attacks, especially, can enable every visitor to be redirected to the attacker’s website, which will often pose as a reputable site, prompting the user for PII, financial info, etc. The worst part is that they’re completely avoidable using simple methods to ensure that both input and output are sanitized, along with a few other measures.
Learn how to detect and prevent XSS, along with other high severity Application Security vulnerabilities on our Vulnerability Knowledgebase.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.