With blogs or articles like this one, readers are aided by punctuation marks. For example, periods tell readers where a sentence ends, while commas either separate articles in lists or insert hard pauses to help separate ideas. With a well-written blog (like this one), the punctuation is almost invisible, just part of the standard background code that we all learned to process many years ago.

But what happens if a hacker gets into this article and inserts weird punctuation marks in the wrong places? Like this:

Without,even! changing. the, text. it? can. make it! much? harder. to? process! the, information!

That is basically what happens with a CRLF injection attack. The CRLF letters stand for Carriage Return and Line Feed, which are used individually or together to note the termination of a line. If an attacker can insert a CR or LF code into an existing application, they can sometimes change its behavior. The effects are less easy to predict compared with most attacks, but can be no less dangerous to the target organization.

In this episode we will learn:

• How attackers can trigger a CRLF injection
• Why CRLF injections are dangerous
• Techniques that can fix this vulnerability.

How do Attackers Trigger a CRLF Injection?

Injecting CRLF characters into existing code and trying to produce a specific result is rather difficult, though not impossible. It's made harder because an attacker would need to use different CRLF combinations depending on the operating system and other factors of the targeted system. For example, modern Windows machines require both a CR and LF to end a line, while over on Linux, only the LF code is needed. HTTP requests always require a precise CRLF code to end a line.

But beyond the fact that CRLF attacks are difficult to implement, and even harder to predict their results, they are initiated in much the same way as other injection type attacks. A malicious user simply enters data into any area on a website or application that allows it, only they enter the CRLF code instead of, or after, normal input data.

For example, an attacker could enter the ASCII code representing a carriage return (%0d) followed by ASCII for a line feed (%0a) at the end of an HTTPS header. The whole query would then look like this:

https://validsite.com/index.php?page=home%0d%0a

If the data is not sanitized or filtered, the above code might allow some strange things to happen on the target application or website.

Why are CRLF Injections Dangerous?

While CRLF injection attacks are less precise than most, they can be fairly dangerous at least some of the time. At the low end, adding an extra line can mess up log files, which might trigger automatic cybersecurity defenses to alert administrators to a non-issue. However, this could be used to divert resources away from an actual incursion occurring at the same time.

But CRLF attacks can also be directly damaging. For example, if an application is designed to accept commands and then search for a specific file, adding a CRLF code to the query might trigger the application to display that process to the screen instead of keeping it hidden, which could provide valuable information for an attacker.

CRLF injections can also be used to create what is called a response splitting attack, where the end of line codes break up a valid response into multiple pieces. That can give hackers control of the header after the CRLF code, which can be used to inject additional code. It can also be used to create an opening where the attacker can fully inject their own code, and likely trigger another form of attack, on any line following the part broken by the CRLF attack.

Eliminating the CRLF Injection Vulnerability

If there is one key message to take away from this series, it's to never, ever trust user input. Most of the vulnerabilities we have covered in this series have involved user input areas in one way or another, and the CRLF injection flaw is no exception.

At any point where a user can enter input, filters must be applied to prevent the injection of unauthorized code that might be misinterpreted by the application or server. For CRLF attacks, locking down HTTP headers is especially important, but you also can't forget GET and POST parameters or even Cookies. One great way to specifically thwart CRLF codes from helping to trigger further injections is to apply HTML encoding to anything and everything sent back to a user's browser.

More Information about CRLF Injections

For further reading, you can take a look at what OWASP says about CRLF injections. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Those of you reading this blog series might notice a lot of similarities between the remote file inclusion vulnerability and the local file inclusion and path traversal vulnerability discussed previously. Their root causes are similar, as are the recommended fixes.

In many ways, the remote file inclusion vulnerability is much more dangerous, and also easier to exploit, than its local file counterpart. As such, it should be found and remedied as soon as possible. Or better yet, web applications should be designed in such a way as to prevent it from occurring in the first place.

In this episode, we will learn:

• How hackers exploit the remote file inclusion vulnerability
• Why allowing remote file inclusion is dangerous
• Techniques that can fix this problem.

How do Attackers Exploit Remote File Inclusion?

The remote file inclusion vulnerability takes advantage of the "dynamic file include" command or mechanism that exists in most programming frameworks. The ability is intended to allow developers to use files located on a secondary server to execute activities on the application server. Obviously, this can be dangerous in the wrong hands.

How attackers exploit this ability is by finding any website or application that allows uncontrolled user input, which can come from things like HTTP headers or input areas in interactive forms. They use that as a launching point to generate file include commands.

For example, if a site uses the GET function to load pages, such as page = request.getParameter("page'); include page; then an attacker could send in a query using the page command, but with a URL of a site they control and file path to the file they want to execute. The query then gets passed to the server and the remote file is executed on the host. The activity is allowed because it is now part of the trusted app.

Why is the Remote File Inclusion Vulnerability Dangerous?

The level of danger posed by remote file inclusion is extremely high. Unlike with local file inclusion vulnerabilities, where files an attacker runs must exist on a host, and also be found by the attacker using trial and error, there are no restrictions like that with remote file inclusion. Obviously, an attacker knows the location of the files they want to exploit since they likely exist on their own machines, or sites they control. The files can also be hand chosen by them, and don't need to exist on the target machine prior to the exploit. The file might even consist of scripts specifically written to exploit a remote host.

In short, once an attacker is able to find and exploit a remote file inclusion vulnerability, there is nothing to stop them from gaining total control over an application or even an entire site. Certainly, no data stored there will be safe from their incursion.

Removing Remote File Inclusion Vulnerability

Never allow user input to pass directly to a file inclusion command for execution. Instead, use an indirect reference map of commands and only execute commands from there. An indirect reference map maps untrusted user input to a set of hardcoded trusted values on the server. Be sure to whitelist any areas where users can input data, and don't forget to include HTTP headers, form parameters and even cookies in that list. Doing that will close any window that an attacker looking to create a file include command can use.

As a bonus, proper sanitization and validation of user-generated content and employing reference maps to execute commands will not only squash the remote file inclusion vulnerability, but quite a few others as well, including this bug's dangerous cousin, the local file inclusion and path traversal exploit.

More Information about Remote File Inclusion

For further reading, you can take a look at the OWASP reference guide for remote file inclusion exploits. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Unlike many vulnerabilities, exploiting local file inclusion and path traversal processes for nefarious purposes requires a sufficiently skilled attacker, a fair amount of time, and perhaps a bit of luck. That is not to say that this vulnerability can be ignored. Skilled attackers can use it to turn internal files against an organization, map out a directory structure or even steal password and user information that can be used for dangerous secondary attacks.

In this episode, we will learn:

• How hackers exploit local file inclusion and path traversal vulnerabilities
• Why allowing unrestricted local file inclusion and path traversal can be dangerous
• Policies and techniques that can be employed to find and fix this problem.

How do Attackers Exploit Local File Inclusion and Path Traversal?

The classic TV detective Columbo used to always say, "Just one more thing" right before delivering a valuable piece of information that would crack open the case at hand. It seemed inconsequential at the time, and was almost always ignored by the suspect, but always proved to be their undoing. The local file inclusion and path traversal vulnerabilities are a lot like that.

The local file inclusion and path traversal vulnerabilities use the dynamic file include mechanism that exists in most programming frameworks such as ASP, JSP and PHP scripts. For local file inclusion, an attacker slips the name of a file that exists on the local server into an area in a web application such as a header or form input area. The application processes the main input as normal, but also the include(page) or similar command. In path traversal, the attacker defines the path to a suspected file, normally using the dot, dot and slash (../) characters as variables. It's very much like Columbo in that the hacker really doesn't care about the first part of the argument. It's simply a means for them to add "just one more thing" at the end.

In either case, the attacker must normally perform a significant amount of trial and error. Unless they are very familiar with how the site is structured, guessing path configurations and file names could take a long time. That said, most sites follow specific patterns, and have more or less similar directories and file names. So it might not take a long as you think. And given that the payout is potentially very lucrative, there is a lot of incentive for hackers to try and exploit local file inclusion and path traversal vulnerabilities once found.

Why are Local File Inclusion and Path Traversal Vulnerabilities Dangerous?

Local file inclusion and path traversal vulnerabilities are dangerous because they can allow attackers to gain access to sensitive or critical files. For data files, the danger is that the hacker could obtain something valuable such as user passwords or other personal information. A primary target is often password or user configuration files since that would provide access to the rest of the site. Databases are also prime targets. Local file inclusion and path traversal vulnerabilities could allow an attacker to steal the entire contents of a database in a worst case scenario.

For executable files, the danger is that getting access to them might allow an attacker to perform malicious activities such as destroying part of a site or even mounting some type of internal denial of service attack by squandering system resources. But the full scope of the danger is only limited by the attacker's ingenuity and skill, and whatever files they can access that already exist on the target server.

Removing the Threat Posed by Local File Inclusion and Path Traversal

The danger posed by local file inclusion and path traversal vulnerabilities can be eliminated with good cybersecurity practices. The most important thing to remember is never allowing user input in "file include" or other commands with similar functions. If an application must allow it, don't directly pass it on. Instead, use an indirect reference map. An indirect reference map takes user input and maps it to a set of hard-coded trusted values which can then be safely used.

As with many other vulnerabilities, pay particular attention to all user-controlled input areas such as cookies, HTTP headers and form parameters. Allowable input should be whitelisted, with everything else explicitly denied. Where this is not possible, use input validation to tightly regulate which values are allowed such as numbers, alphanumeric values etc.

More Information about Local File Inclusion and Path Traversal

For further reading, you can take a look at the OWASP testing guide for local file inclusion and path traversal exploits. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Even if you have completely secured an application server and the backend systems it uses, communications might still be vulnerable to snooping if you have insufficient transport layer protection. In the physical world, the reason that hard currency is moved around using armored cars is to provide protection while it's in transit. It really doesn't matter how secure a store or a bank is if the money it generates is being loaded into a golf cart for a drive across town.

The same can be said of transport layers in the cyber realm. Even if an application is secure, there is still a critical vulnerability if the information coming into it is sent with no protection. And there is a second vulnerability with some apps if they additionally send information to other servers or a database. That information might be exposed to insiders who have no business snooping those transactions.

To fully protect users and data requires protecting the transport layer. Only by doing that can you fully secure an entire transaction from end to end.

In this episode, we will learn:

• How hackers can exploit insufficient transport layer protection
• Why not protecting the transport layer is so dangerous
• What can be done to secure the transport of all data moving into and through an application or server.

How do Attackers Exploit Insufficient Transport Layer Protection?

Insufficient transport layer protection can enable attacks at two points within your data stream. The most commonly exploited spot sits between a user and the application server. If information is sent in the clear, or with weak encryption, then hackers will be able to monitor, steal and possibly change that information. This might allow hackers to steal a user's credit card, their login credentials or anything else sent into the application server. Even if the server itself is secure, a hacker monitoring the unsecure channel between it and users could get nearly unrestricted access to a lot of information.

The second point which is often left unprotected is the transport layer between an application and the rest of the network. For example, an application server might process online shopping orders and then send them on to a fulfillment system, or data might simply be offloaded to a database for storage. If those internal channels are unprotected, inside users might be able to see that information.

While it's nice to believe that all internal users are good people, the fact is that insider threats are on the rise in a lot of industries. Insiders have been caught taking bribes in return for collecting sensitive information for attackers or competitors. And having access to something like thousands of valid credit cards might simply be too tempting for some people to ignore.

In terms of attack techniques, it's not very difficult to intercept unprotected communications. Even low level hackers know how to perform man-in-the-middle attacks against unencrypted data streams. If they don't, there are videos online that can train them in less than half an hour.

Why are Insufficient Transport Layer Protection Vulnerabilities so Dangerous?

Having insufficient or nonexistent protection on transport layers is dangerous because it makes it extremely easy for hackers to gather sensitive information. They don't have to break into your app server or hack your network. They simply set up a man in the middle attack and read everything being sent into a server from users. This can include usernames and passwords which can be used to bypass security in the future using valid credentials. Depending on the application, this might also include credit card information or other personal data about users.

And it's important to note that all of this snooping is taking place outside of your network. If you are using insecure transport channels, there is no way to know if someone is capturing that information. Normally the first sign is when lots of users begin reporting compromised accounts or credit card purchases, and the common factor is your application " not a good spot to be in. Hackers can also modify information once they have it, changing the delivery address for example, or even inserting malicious scripts into the server response before passing it along to users.

On the backend, failure to secure the transport layer exposes data to insiders. It's probably a lot less likely that an insider is snooping the transport layer compared to hackers from the outside doing the same thing. But its also more dangerous if it happens, because the insider threat will be able to see not only the user data, but also any proprietary information added by the app server before sending those packets along.

Eliminating Insufficient Transport Layer Protection Vulnerabilities

As dangerous as insufficient transport layer protection can be, it's also not incredibly difficult to properly secure all of your transport channels. It starts with the backend infrastructure. This should be exclusively HTTPS, be sure not to mix HTTPS and HTTP on a site. Finally, maintain a valid SSL certificate with a minimum key size of 2048 bits while forcing all users to interact using secured browsers with HTTP Strict Transport Security (HSTS).

Once the infrastructure is in place, developers should use a strong protocol to protect the transport layer. Ideally TLS 1.2 should be used, though TLS 1.1 and 1.0 are also acceptable if absolutely necessary. Once that is in place, weak protocols like SSLv2 should be completely disabled and never supported.

Care should also be taken to ensure that cryptographic ciphers are sufficiently powerful on the backend. Ideally, the minimum session key size should be 128 bits. Like with protocols, support for weak cryptographic algorithms such as DES and RC4-40 should be disabled. And finally, don't consider an application truly secure until both the server itself and all the data paths leading into and out of it are sufficiently protected.

More Information about Insufficient Transport Layer Protection Vulnerabilities

For further reading, you can take a look at the OWASP guide to protecting transport layers. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

XML injection attacks are nasty little exploits invented by hackers to help them compromise systems hosting XML databases. This includes the kinds of things that come to mind when one thinks about traditional databases - detailed stores of information about anything from medicines to movies. Some XML datastores are also used to check for authorized users, so injecting new XML code into them can create new users that the host system will accept from that point forward.

For an attacker to implement an XML injection, there needs to be an application which relies on, or at least accesses, an XML database. Whenever that happens, and user input is not properly vetted, new XML code can be added to the datastore. Depending on the skill of the attacker, adding new XML code can do quite a lot of damage, or even provide access to the entire database.

As you read on, you might discover that XML injection is closely related to the SQL injection attacks that we previously covered. That's because even though they target different types of databases, they are extremely similar. And thankfully, the fixes are similar as well. Learning how to defeat one type of attack will put you well ahead of the game when working to prevent the other.

In this episode, we will learn:

• How XML injections work
• Why they are so dangerous
• How you can put defenses in place to completely stop them.

How do Attackers Trigger XML Injections?

XML injections are successful whenever an unauthorized user is able to write XML code and insert it into an existing XML database. This only requires two things to work: an application that relies on, or connects to, an XML database and an unsecured data pathway for the attacker to launch their attack.

XML injections are almost always successful if user input isn't sanitized or otherwise restricted before being sent to a server for processing. This can allow attackers to write their own code, or inject it, at the end of their normal query string. If successful, this tricks the server into executing the XML code, allowing it to add or delete records, or even reveal an entire database.

Hackers implement an XML injection attack by adding XML code to a normal query. This can be anything from a search field to a login page. It might even include things like cookies or headers.

For example, in a registration form, a user might add the following code after the username or password field:

<user></user>
<role>administrator</role>
<username>John_Smith</username><password>Jump783!Tango@12</password>

In this example, a new user named John_Smith would be created with administrator access. At least the new user is employing good password density rules. Too bad they are actually an attacker.

Hackers don't necessarily need to always hit a home run like that to be successful with XML injections. By manipulating their queries and recording the various error messages that the server returns, they may be able to map out the structure of the XML database. And that information can be used to enhance other types of attacks.  

Why are XML Injections so Dangerous?

The level of danger involved in an XML injection attack depends on what information is stored within the targeted XML database, or how that information is being used. For example, in the case of an XML database being used to authenticate users, an XML injection can give an attacker access to the system. It might even allow them to become an administrator on the targeted network, which of course is an extremely dangerous situation.

For XML injections levied against more traditional databases, the danger is in having that information stolen, having incorrect data added to the store, or possibly having good data overwritten. XML code is not very difficult to learn, and some of the commands can be extremely powerful, overwriting entire information fields or even displaying the contents of a datastore.

Generally, nobody builds a database unless the information stored there has value. Hackers know this, which is why they often target them. If that data includes things like personal information on employees or customers, having it compromised can lead to reputation loss, financial consequences, heavy fines or even lawsuits.  

Stopping XML Injection Attacks

XML Injections are fairly common due to the low degree of difficulty in pulling one off, and the prevalence of XML databases. But these attacks have been around for a long time. As such, there are several ironclad fixes that will prevent them from ever executing.

One of the best methods for stopping the attacks is to design an application to only use precompiled XML queries. This limits the functionality of the queries to an authorized subset of activities. Anything that comes in with extra arguments or commands that don't match the precompiled query functions simply won't execute. If you don't want to be quite so restrictive, you can also use parameterization. This restricts user input to specific types of queries and data, for example only using integers. Anything that falls outside those parameters is considered invalid and forces the query to fail.

It's also a good idea to pair precompiled or parameterized queries with customized error messages. Instead of sending back the default, descriptive error messages from a failed query, applications should intercept those responses and replace them with a more generic message. Ideally, you will want to tell a user why the query failed, but not give them any information about the database itself. If you restrict those custom messages to just a few choices, hackers will not be able to compile any useful reconnaissance from failed queries.

XML injections were highly successful when they were first developed. But given how long ago that was, today we can easily construct defenses that can no longer be breached.

More Information about XML Injections

For further reading, you can take a look at the OWASP writeup on XML injections. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

While we have been exploring topics in these blogs, we've uncovered quite a few dangerous vulnerabilities and malicious exploits that hackers employ to assault networks and bypass defenses. They run quite the gamut from exploiting weaknesses in programming languages, to injecting code using various formats, to hijacking data in transit. It's quite a range of threats, but whenever any of them are successful, there is often one common component shared among their victim's applications.

Insufficient logging and monitoring is one of the most dangerous conditions that can exist within an application's defensive structure. If this vulnerability or condition exists, then almost any advanced attack made against it will eventually be successful. Having insufficient logging and monitoring means that attacks or attempted attacks are not discovered for a very long time, if at all. It basically gives attackers the time they need to find a useful vulnerability and exploit it.

In this episode we will learn:

• How attackers can use insufficient logging and monitoring
• Why insufficient logging and monitoring is dangerous
• Techniques that can fix this vulnerability.

How do Attackers Exploit Insufficient Logging and Monitoring?

At first, attackers don't know if a system is being properly monitored, or if log files are being examined for suspicious activity. But it's easy enough for them to find out. What they will sometimes do is launch some form of inelegant, brute force type of attack, perhaps querying a user database for commonly used passwords. Then they wait a few days and try the same kind of attack again. If they are not blocked from doing it the second time, then it's a good indication that nobody is carefully monitoring the log files for suspicious activity.

Even though it's relatively simple to test an application's defenses and gauge the level of active monitoring happening, it's not a requirement of successful attacks. They can simply launch their attacks in such a way as to make as little noise as possible. More often than not, the combination of too many alerts, alert fatigue, poor security configurations or simply a plethora of exploitable vulnerabilities means that they will have plenty of time to complete their goals before defenders even realize that they are there.

Why is Insufficient Logging and Monitoring Dangerous?

Insufficient logging and monitoring is dangerous because it gives attackers time to not only launch their attacks, but to complete their goals long before defenders can launch a response. How much time depends on the attacked network, but different groups like the Open Web Application Security Project (OWASP) puts the average response time for breached networks at 191 days or longer.

Think about that for a moment. What would happen if robbers held up a bank, people called the police, and it took them half a year to respond?

The robbers would be long gone by the time police arrived. In fact, that same bank can be robbed many more times before the police even respond to the first incident.

It's like that in cybersecurity too. Most of the high profile breaches that you hear about on the news were not smash and grab type of operations. Often times the targeted organization only learns about a breach after the attackers have had more or less full control over data for months or even years. This makes insufficient logging and monitoring one of the most dangerous situations that can happen when trying to practice good cybersecurity.

Eliminating Insufficient Logging and Monitoring

Preventing insufficient logging and monitoring requires two main things. First, all applications must be created with the ability to monitor and log server-side input validation failures with enough user context for security teams to identify the tools and techniques, if not the user accounts, that attackers are using. Or, such input should be formatted into a language like STIX (Structured Threat Information eXpression) which can be quickly processed by security tools to generate appropriate alerts.

Secondly, it's not enough to simply generate good alerts, though that is a start. Organizations also need to establish roles and responsibilities so that those alerts are investigated in a timely fashion. Many successful breaches actually triggered alerts on the attacked networks, but those warning were not heeded because of questions of responsibility. Nobody knew whose job it was to respond, or assumed that someone else was looking into the problem.

A good place to start when assigning responsibilities is adopting an incident response and recovery plan like the one recommended by the National Institute of Standards and Technology (NIST) in special publication 800-61. There are other reference documents, including ones specific to various industries, and they don't have to be followed to the letter. But forming a plan defining who within an organization responds to alerts, and how they go about doing that in a timely fashion, is critical.

More Information about Insufficient Logging and Monitoring

For further reading, you can take a look at what OWASP says about insufficient logging and monitoring. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Ready to find, fix and eliminate insufficient logging and monitoring right now? Head to our training arena: [Start Here]

Coding a website or application with the ability to process unvalidated redirects and forwards can be extremely dangerous for both your users and your organization. This common mistake is often exploited by hackers looking to perpetrate phishing scams, or to gain access to pages and information that would normally be restricted.

Whenever a web application is designed to forward users to new pages, there is the danger that those requests can be manipulated or hijacked. This can happen if there is no validation process in place to prevent forwarding parameters from pointing at unintended destinations.

The good news is that unvalidated redirects and forwards are one of the easier vulnerabilities to eliminate from your environment. Once removed, you can take a few simple steps to ensure that they are never generated in the future.

In this episode, we will learn:

• How hackers exploit unvalidated redirect and forward vulnerabilities
• Why allowing unvalidated redirects and forwards can be dangerous
• Policies and techniques that can be employed to find and fix this problem.

How do Attackers Exploit Unvalidated Redirects and Forwards?

Attackers must first find a web application that is set to forward users to a specific page or pages. If the destination page is defined in the code, there is no vulnerability. For example, in Java, this would be a safe, pre-defined way of sending a user to a new location without requiring them to perform any actions, such as clicking on a hyperlink.

response.sendRedirect("http://www.knownsafesite.com");

The vulnerability occurs if the site is programmed to instead accept user input for the redirect, or if the parameter is left open, perhaps to obtain the information from another source. For example, a developer could use the "url'GET parameter.

response.sendRedirect(request.getParameter("url"));

While this gives more flexibility, it also creates the unvalidated redirects and forwards vulnerability. Hackers can add information after the forward slashes to trigger a redirect to whatever site they choose, perhaps as part of a phishing e-mail. Users see the trusted domain in the first part of a link and don't realize that the website may forward them to the hacker's site.

Why are Unvalidated Redirects and Forwards so Dangerous?

The danger posed by allowing unvalidated redirects and forwards can be significant. For users, the biggest danger is that they can become victims of phishing attacks. Because they see the top-level URL, they are more likely to trust a phishing e-mail or other communication and click on a link. And if the page they are redirected to looks like the real page, the deception can be quite effective. They might share their user name, passwords or other credentials and never suspect that they are being manipulated.

Removing the Threat Posed by Unvalidated Redirects and Forwards

Unvalidated redirects and forwards begin life while an application is being developed. They can be eliminated after the fact, but the easiest way to eliminate them is simply not allowing user parameters or open strings as part of any redirect or forward function in the first place. Instead, tightly define the URLs where users will be forwarded, eliminating variables and denying attackers room to maneuver. Better yet, consider not using redirects and forwards at all.

If there is absolutely no way to avoid having variables as part of a redirect or forward process, then there must be a validation process put in place to ensure that the redirect is going to one of a set of valid destinations. Finally, use mapping values instead of actual URLs. Hackers will instead try to use URL information, and likely wont be able to guess at the mapping scheme even if they suspect one is in use.

More Information about Unvalidated Redirects and Forwards

For further reading, you can take a look at the OWASP reference pages on unvalidated redirects and forwards. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Take care of unvalidated redirects and forwards once and for all. Apply your new knowledge and test your skills on our gamified training platform: [Start Here]

Code injection attacks are among the most common, and also the most dangerous, that many websites and applications will encounter. They run the gamut both in terms of sophistication and in the danger that they pose, but nearly any site or app that accepts user input could be vulnerable. In fact, this kind of attack is one that almost every cybersecurity defender will need to deal with at some point in their career, and will probably grapple with it multiple times.

A code injection attack can occur whenever an application or website accepts input from users. This can be as simple as providing a search function or asking a user to enter their identification information. The attack happens when a malicious user enters code into the open field instead of normal text input. Their goal is to have the server mistake the input for valid code, and then execute whatever functions the attacker desires.

While code injection attacks are extremely common, so are the available defenses that can be used to stop them. In this episode, we will learn:

• How they work
• Why they are so dangerous
• How you can put defenses in place to stop them.

How do Attackers Use Code Injection?

Although the specific details about code injection attacks change depending on the programming language used, any app or website can be vulnerable so long as it allows a user to input data. Code injection attacks have been triggered for SQL, HTML, XML, CSS and every other common programming language.

First, an attacker must locate vulnerable code within an application, normally at a point where users are allowed to enter their own input. For example, this code takes the PHP eval() function and passes it along to a user to modify, without any sort of validation of the return string.

$myvar = "varname";
$x = $_GET[arg];
eval("\$myvar = \$x;");

A clever attacker could easily add their own string to the eval function, even executing system commands if they choose.

/index.php?arg=1; system(id)

It's important to note that while code injection attacks can involve sending system commands, they are not restricted to just doing that. In fact, with code injection attacks, hackers are only limited by the functionality of the language itself. In our example, an attacker could program the targeted system to do almost anything allowed by the PHP framework.

Why are Code Injection Attacks so Dangerous?

Code injection attacks are potentially extremely dangerous depending on the skill of the attacker. They can do anything that the programming language allows, which puts them on the same footing as the app's programmers. An attacker could practically write their own app and have it executed within the target environment.

Even less skilled attackers can be dangerous. Instead of writing their own application or code strings, they can simply order the targeted system to accept and install pre-programmed malware. This could lead to site defacement, ransomware attacks or even become the basis for a phishing campaign leveled against the site's users.

Most of the time, code injection attacks are used to steal things like user lists and passwords, or to gain valuable reconnaissance into a system targeted for further compromise. But be warned, a skilled coder can do almost anything with a code injection attack, which is why it's critical that every potential instance of them are discovered and removed from your environment.

Trust No-One! (Or At Least, Not Users)

When eliminating code injection attack vulnerabilities, the first place to look is anywhere that asks for, or allows, user input. Anything inputted by a user is not to be trusted under any circumstances. If you allow user input without filtering or examination, you are basically inviting attackers to take a free shot at compromising your system or even your network.

Although it is not always possible, the best way to thwart code injection attacks is to prevent functions from executing or interpreting user input directly. Perhaps users can be given a choice of static options instead of free reign to enter their own queries, with the application programmed to only accept those limited choices as valid. It may not always be appropriate to do that, but using it where possible can eliminate code injections before they start.

For areas where users need to enter their own input, tight controls must be placed on that data. Assuming everything is a potential attack is a good place to start. Enforcing least privilege policies such as read-only user access, on both the client and server side, can prevent most code from executing.

The other good defense is to implement application-wide filters and sanitization on everything any user inputs. Developers have been aware of code injection attacks for years, and libraries of proven filters exist for every framework and language. When applying those filters, be sure to do so not just on the obvious user input areas or against common parameters like Get and Post commands, but also against cookies and HTTP headers.

Applying a Correction for Code Injection

Removing unnecessary user input areas from your environment, enforcing least privilege principles and using the latest filtering and sanitization tools to inspect and detect potential attacks can shut the door on this dangerous vulnerability. Having the mindset of never trusting user input will also serve you well moving forward. Do all that, and you can stay one step ahead of this dangerous type of attack.

For further reading, you can take a look at the OWASP write-up on code injection. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Face code injection head-on, right now. Take the challenge on our gamified training platform: [Start Here]

When you build a business application, whether for internal use or external use by your customers, you probably don't let every user perform every single function. If you do, you may be vulnerable to broken access control.

Let's take a look at what broken access control is, why it's so dangerous, and how to fix it.

Understand Broken Access Control

Broken access control occurs when application code does not have the proper security or access checks in place. It can also occur when an application is misconfigured in some way, allowing access to functions or pages to which the user should not have access.

If you handle the finances of your company, you may have access to deposit money into certain accounts or transfer money between your company's accounts. However, you shouldn't have access to withdraw cash from those accounts or transfer money to other accounts. If the proper access checks are not present, then your employees may be able to perform more functions than necessary.

These checks can either be done within the code or in configuration files. For example, there may be XML configuration files that tell the web application framework which users are allowed to access which pages. This ensures that users can only access the functions they are authorized to use.

Why Broken Access Control is Dangerous

Consider this example: An attacker has realized that your user account creation code can be manipulated, allowing the attacker to create an admin user with a simple post request. They can send a request with the username and password, and then change it en route to include the role of admin in the URL as a parameter, or in the body of the request. The attacker logs into the application and is instantly given administrator rights.

It doesn't always have to be a malicious attacker penetrating a system. Without proper access controls, sensitive information that shouldn't be shared between departments may leak out. Imagine if any employee in the company could see HR payroll data or financial data. What would happen if any employee could see that layoffs are coming because of the poor financial situation of the company? This could be damaging to your morale and your company's reputation.

Sensitive information of customers could also be lost. Companies often store personal information of customers that use their services. Be careful not to accidentally expose this because of a lack of access control. For example, if your system gives users the ability to request their health record, do they also have the ability to request and see the health information of others? If the URL contains a customer ID number, attackers could increment that customer ID number over and over again until they find one that matches another customer, thus revealing their personal data.

Defeat Broken Access Control

Role-based access control (RBAC) is a very effective tool for implementing sound access control. Those using Active Directory may be familiar with the idea of creating groups and giving access to certain items across the group, instead of to the individual. Applications work the same way, using roles to define who is allowed to see what.

This has two advantages. First, a function doesn't have to be changed when somebody leaves the administrator role. If somebody was previously an administrator and now no longer should be, then you simply place a new person into the administrator role and remove the previous person from the role. The code checks to see if the user has the administrator role instead of checking to see if each individual user has access to a certain page or function.

The second benefit is avoiding a maintenance nightmare. Access control that is so granular that every person has associations with every single possible function or page will be impossible to manage over time. Roles make things much easier, because multiple people can be added to a role. One role may include the entire company, while another may have only five people. This makes managing the roles more efficient, as there will be fewer roles to manage. A company of 10,000 people could have only 100 roles instead of 10,000 times the number of functions in your application. Research your chosen application framework to see what options exist for robust access control.

It is also critical to use function-level access control. Protect access to all functions by requiring users to pass certain access control checks. Use the principle of least privilege, denying access by default and only opening access on an as-needed basis. It can be difficult to remember to implement access control for each function. Use a central component to manage and enforce access control.

Protect Your Sensitive Functions

Broken access control can leave your data and your application wide open for attack and exploitation. Customer data that is not protected properly could lead to a massive data breach, hurting your reputation and your revenue.

Broken access control could also lead to account takeover if attackers are able to access functionality they shouldn't access. Use proper functional level access control and you'll keep your application safe from malicious attackers, and even accidental insiders.

Think you're all over functional level access? You can challenge yourself to repair broken access control now: [Start Here]