Tag Archives: static analysis

JavaScript in an HREF or SRC Attribute

The anchor (<a>) HTML tag is commonly used to provide a clickable link for a user to navigate to another page. Did you know it is also possible to set the HREF attribute to execute JavaScript. A common technique is to use the onclick event of the anchor tab to execute a JavaScript method when the user clicks the link. However, to stop the browser from actually redirecting the HREF can be set to javascript:void(0);. This cancels the HREF functionality and allows the JavaScript from the onclick to execute as expected.

In the above example, notice that the HREF is set with a value starting with “javascript:”. This identifier tells the browser to execute the code following that prefix. For those that are security savvy, you might be thinking about cross-site scripting when you hear about executing JavaScript within the browser. For those of you that are new to security, cross-site scripting refers to the ability for an attacker to execute unintended JavaScript in the context of your application (https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)).

I want to walk through a simple scenario of where this could be abused. In this scenario, the application will attempt to track the page the user came from to set up where the Cancel button will redirect to. Imagine you have a list page that allows you to view details of a specific item. When you click the item it takes you to that item page and passes a BackUrl in the query string. So the link may look like:

https://developsec.com/item.php?backUrl=/items.php

On the page, there is a hyperlink created that sets the HREF to the backUrl property, like below:

<a href=”<?php echo $_GET[“backUrl”];?>”>Back</a>

When the page executes as expected you should get an output like this:

<a href=”/items.php”>Back</a>

There is a big problem though. The application is not performing any type of output encoding to protect against cross-site scripting. If we instead pass in backUrl=”%20onclick=”alert(10); we will get the following output:

<a href=”” onclick=”alert(10);“>Back</a>

In the instance above, we have successfully inserted the onclick event by breaking out of the HREF attribute. The bold section identifies the malicious string we added. When this link is clicked it will prompt an alert box with the number 10.

To remedy this, we could (or typically) use output encoding to block the escape from the HREF attribute. For example, if we can escape the double quotes (” -> &quot; then we cannot get out of the HREF attribute. We can do this (in PHP as an example) using htmlentities() like this:

<a href=”<?php echo htmlentities($_GET[“backUrl”],ENT_QUOTES);?>”>Back</a>

When the value is rendered the quotes will be escapes like the following:

<a href=”&quot; onclick=&"alert(10);“>Back</a>

Notice in this example, the HREF actually has the entire input (in bold), rather than an onclick event actually being added. When the user clicks the link it will try to go to https://www.developsec.com/” onclick=”alert(10); rather than execute the JavaScript.

But Wait… JavaScript

It looks like we have solved the XSS problem, but there is a piece still missing. Remember at the beginning of the post how we mentioned the HREF supports the javascript: prefix? That will allow us to bypass the current encodings we have performed. This is because with using the javascript: prefix, we are not trying to break out of the HREF attribute. We don’t need to break out of the double quotes to create another attribute. This time we will set backUrl=javascript:alert(11); and we can see how it looks in the response:

<a href=”javascript:alert(11);“>Back</a>

When the user clicks on the link, the alert will trigger and display on the page. We have successfully bypassed the XSS protection initially put in place.

Mitigating the Issue

There are a few steps we can take to mitigate this issue. Each has its pros and many can be used in conjunction with each other. Pick the options that work best for your environment.

  • URL Encoding – Since the HREF is meant to be a URL, you could perform URL encoding. URL encoding will render the javascript benign in the above instances because the colon (:) will get encoded. You should be using URL encoding for URLs anyway, right?
  • Implement Content Security Policy (CSP) – CSP can help limit the ability for inline scripts to be executed. In this case, it is an inline script so something as simple as ‘Content-Security-Policy:default-src ‘self’ could be sufficient. Of course, implementing CSP requires research and great care to get it right for your application.
  • Validate the URL – It is a good idea to validate that the URL used is well formed and pointing to a relative path. If the system is unable to parse the URL then it should not be used and a default back URL can be substituted.
  • URL White Listing – Creating a white list of valid URLs for the back link can be effective at limiting what input is used by the end user. This can cut down on the values that are actually returned blocking any malicious scripts.
  • Remove javascript: – This really isn’t recommended as different encodings can make it difficult to effectively remove the string. The other techniques listed above are much more effective.

The above list is not exhaustive, but does give an idea of ways to help reduce the risk of JavaScript within the HREF attribute of a hyper link.

Iframe SRC

It is important to note that this situation also applies to the IFRAME SRC attribute. it is possible to set the SRC of an IFRAME using the javascript: notation. In doing so, the javascript executes when the page is loaded.

Wrap Up

When developing applications, make sure you take this use case into consideration if you are taking URLs from user supplied input and setting that in an anchor tag or IFrame SRC.

If you are responsible for testing applications, take note when you identify URLs in the parameters. Investigate where that data is used. If you see it is used in an anchor tag, look to see if it is possible to insert JavaScript in this manner.

For those performing static analysis or code review, look for areas where the HREF or SRC attributes are set with untrusted data and make sure proper encoding has been applied. This is less of a concern if the base path of the URL has been hard-coded and the untrusted input only makes up parameters of the URL. These should still be properly encoded.

Does SAST and DAST Really Require Security Experts To Run Them?

There is no argument that automated tools help quickly identify many of the vulnerabilities found in applications today. Tools are typically categorized into one of the following three categories:

  • Dynamic Application Security Testing (DAST) – analyzes the running application.
  • Static Application Security Testing (SAST) – analyzes the source or byte code of the application.
  • Interactive Application Security Testing (IAST) – uses agents installed on the web server to instrument the application and analyze it at runtime. This gives access to both dynamic and static details.

These tools are becoming more popular within organizations as part of their application security programs. While there is still a large gap that can only be filled by manual testing, the automated tools are a good first step.

Are these security tools or development tools?

This depends on what your goal is. Ultimately, they are focused on finding security flaws which make them a “security” tool, however that doesn’t mean it is meant for the security team. I have been presenting for a long time on the idea that many of these tools should be considered development tools and placed in the hands of development and QA. To understand where they fit in your organization, you have to understand how you want to use them.

The application team should be using these tools to help quickly identify security bugs earlier on in the SDLC. To make this work efficiently, this should be considered a development tool. Let’s look at how SAST is used by developers. Developers have the ability to scan their source code using their chosen SAST tool. In many cases, these tools may provide an IDE plugin to make the process easier. As the developer writes their code, they can perform regular scans in smaller increments to quickly identify potential security threats. Once identified, the code can be corrected before it even leaves the development queue. In other instances, SAST is embedded into the continuous integration pipeline and scans can be run on check-in or other predefined activities. The results are immediately available to the development teams to review and make corrections.

The security team should be using these tools differently than the development teams. Security is typically more interested in the risk an application presents to the application. In the use of these tools, they provide valuable information that can be reported on to help analyze that risk. The security team should also be involved in the creation of policies and procedures around the implementation and use of the tools provided.

I thought only security experts can run these tools?

I believe this is a myth that only security experts can run these types of tools. Developers have long had static analysis tools built right into their IDEs, they just didn’t have a focus for security flaws. QA groups use all sorts of automated tools to assist in application testing. Lets take a look at each of the tool categories again.

DAST

Dynamic scanners usually require at minimum three pieces of information to get started: URL, Username, Password. Most of these scanners are either a windows or web application with a GUI. Setting up a scan is usually not to complex and fairly straightforward. I will admit that some applications, depending on how the login works or how routing is configured, can require a more complex setup. Depending on the scanner, you may be able to perform other advanced settings, but these are not difficult to learn.

Once the scan has completed, the results are provided in a GUI as well. The GUI typically provides a simple way to then view each of the findings identified, including the request and response the scanner sent and received. In dynamic scanning, the request and response are helpful in identifying where the issue is in the application. The tool will also usually provide a description of the vulnerability and references to more information. Based on my experience, reviewing findings in the provided GUI is much more efficient than trying to review an exported PDF of the results. A GUI that provides easy navigation is much better received than a 100-200 page PDF report that can’t really be consumed.

Dynamic scanning fits right into the QA process of scanners and can be easily executed by the QA or development team. This is good, because it can be executed against the QA or other pre-prod instances which are owned by the QA and development groups.

SAST

Static scanners analyze your binaries or source code. As expected, they need either the source code itself, or a compiled version of the code. Depending on the tool, you may have to submit the binaries to a service or select them using a local interface. The most difficult part in the process is usually getting the code to compile correctly with debug symbols and components. This compilation is usually done by the development team or DevOps if that has been implemented.

Once the scan is complete, the results are provided either in a web interface or in a local GUI. These results can then be inspected to view details about the issue, just like in the DAST solutions. The big difference being that in SAST you won’t see a request/response, rather you see the file and line of code indicated as well as the source and sink of the vulnerability. The source and sink help trace the data as it passes through the application to the vulnerable line of code. This is useful in helping understand the vulnerability to resolve it. There is a lot of efficiency gained in being able to view these details in a simple manner. The other option is exporting the results to a PDF file which is very inefficient.

Due to the results referencing source code, developers are put into an environment they understand. With some understanding of how security flaws work and are addressed, developers can review the results and take appropriate actions to address them.

IAST

Interactive testing uses an agent on the web server to instrument the application. Basically, it injects code into the application to analyze it as it runs. Due to performance hits, this is a great tool for pre-production environments. It also relies on the code being executed.. basically, if your application is not being used, it won’t analyze the code. This also makes it great for a QA environment or regression testing environment. The setup just requires installing the agent onto the server. The results are displayed, as they are found, in a web interface. These results include the source code and the request/response values. Having direct access to the tool provides an efficient way to view the details to then provide remediations to them.

Review how you use these tools

It has been my experience that more than just security experts can run any of these tools. There may be some tweaking that can be done and requires learning how the tools works, but this is something anyone on the dev or QA teams can adapt to. Take a look at your current program. If you are using any of these tools, look at how you are using them and who has access. Is your current process efficient? Does it make it harder than it needs to be? If you are not using these tools and looking to implement any of them, look at the resources you have and get the development teams involved. Think about where you want these tools to sit and how you want to take advantage of them. They don’t have to be locked down to a security team. Use the resources you have and allow the application teams to take ownership of the tools that will help them create more secure applications.

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.

Static Analysis: Analyzing the Options

When it comes to automated testing for applications there are two main types: Dynamic and Static.

  • Dynamic scanning is where the scanner is analyzing the application in a running state. This method doesn’t have access to the source code or the binary itself, but is able to see how things function during runtime.
  • Static analysis is where the scanner is looking at the source code or the binary output of the application. While this type of analysis doesn’t see the code as it is running, it has the ability to trace how data flows the the application down to the function level.

An important component to any secure development workflow, dynamic scanning analyzes a system as it is running. Before the application is running the focus is shifted to the source code which is where static analysis fits in. At this state it is possible to identify many common vulnerabilities while integrating into your build processes.

If you are thinking about adding static analysis to your process there are a few things to think about. Keep in mind there is not just one factor that should be the decision maker. Budget, in-house experience, application type and other factors will combine to make the right decision.

Disclaimer: I don’t endorse any products I talk about here. I do have direct experience with the ones I mention and that is why they are mentioned. I prefer not to speak to those products I have never used.

Budget

I hate to list this first, but honestly it is a pretty big factor in your implementation of static analysis. The vast options that exist for static analysis range from FREE to VERY EXPENSIVE. It is good to have an idea of what type of budget you have at hand to better understand what option may be right.

Free Tools

There are a few free tools out there that may work for your situation. Most of these tools depend on the programming language you use, unlike many of the commercial tools that support many of the common languages. For .Net developers, CAT.Net is the first static analysis tool that comes to mind. The downside is that it has not been updated in a long time. While it may still help a little, it will not compare to many of the commercial tools that are available.

In the Ruby world, I have used Brakeman which worked fairly well. You may find you have to do a little fiddling to get it up and running properly, but if you are a Ruby developer then this may be a simple task.

Managed Services or In-House

Can you manage a scanner in-house or is this something better delegated to a third party that specializes in the technology?

This can be a difficult question because it may involve many facets of your development environment. Choosing to host the solution in-house, like HP’s Fortify SCA may require a lot more internal knowledge than a managed solution. Do you have the resources available that know the product or that can learn it? Given the right resources, in-house tools can be very beneficial. One of the biggest roadblocks to in-house solutions is related to the cost. Most of them are very expensive. Here are a few in-house benefits:

  • Ability to integrate directly into your Continuous Integration (CI) operations
  • Ability to customize the technology for your environment/workflow
  • Ability to create extensions to tune the results

Choosing to go with a managed solution works well for many companies. Whether it is because the development team is small, resources aren’t available or budget, using a 3rd party may be the right solution. There is always the question as to whether or not you are ok with sending your code to a 3rd party or not, but many are ok with this to get the solution they need. Many of the managed services have the additional benefit of reducing false positives in the results. This can be one of the most time consuming pieces of a static analysis tool, right there with getting it set up and configured properly. Some scans may return upwards of 10’s of thousands of results. Weeding through all of those can be very time consuming and have a negative effect on the poor person stuck doing it. Having a company manage that portion can be very beneficial and cost effective.

Conclusion

Picking the right static analysis solution is important, but can be difficult. Take the time to determine what your end goal is when implementing static analysis. Are you looking for something that is good, but not customizable to your environment, or something that is highly extensible and integrated closely with your workflow? Unfortunately, sometimes our budget may limit what we can do, but we have to start someplace. Take the time to talk to other people that have used the solutions you are looking at. Has their experience been good? What did/do they like? What don’t they like? Remember that static analysis is not the complete solution, but rather a component of a solution. Dropping this into your workflow won’t make you secure, but it will help decrease the attack surface area if implemented properly.

This article was also posted at https://www.jardinesoftware.net