Tag Archives: applicaiton security

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.

Blue Cross Mails USB sticks – Take-Aways

You have information you want to share with your customers, but how do you do it securely? How often have you heard not to click links sent via email? You shouldn’t plug in random USB drives to your computer. From a marketing perspective, how do you get large amounts of information, such as videos and specific information, out to your customers?

In a report by Fierce Healthcare (http://www.fiercehealthcare.com/privacy-security/bcbs-alabama-re-evaluates-usb-marketing-campaign-amid-security-concerns) it appears that BCBS of Alabama thought that sending out some fancy USB drives with benefit information was the right choice. Apparently the drive contained videos and other information about benefits for the company.

As you can guess, there was lots of skepticism around the method. We are taught in many security awareness training sessions to never plug untrusted USB drives into our devices. This is a common tactic used during penetration tests where they drop USB drives in the parking lot or in public places to see if someone will plug it in. Once plugged in, it may allow external access to the system for the attacker. Of course, this depends on the controls in place on the system it was plugged into.

You might wonder why we still see USB drives still passed out at conferences. There are still people that do this and you might consider those as trusted because you feel you received them in person. A company representative handed it to you, so it must be safe right? Well.. not necessarily. You should still proceed with caution.

In regards to mailing the drive, there appears to be an assumption of trust. This may be due to the fact that it was physically sent to you, vs. an item that was emailed. It came through the mail system, it had the corporate branding, even the right return address. The key factor is that all of those things can be spoofed. It is simple to create a letter with a company logo and branding and to set the return address to something other than your personal address. The mail system isn’t designed to verify trust in who sent a letter. Instead, it is meant to hopefully put trust in the fact that if you send mail, it will arrive at its destination.

Take Aways

When we analyze the situation, it helps us decide how to better review our systems to understand our risks and controls. There are a few things you can do to help reduce the risk of these types of potential attacks or situations.

Review your security awareness training to see how it covers USB drives and the policies around them. Are your users trained on how to handle a situation where they receive a USB drive from an untrusted source? Do they know who to contact to make sure it is properly analyzed before they attempt to use it?

Work with your marketing teams to determine how different campaign types work and which ones are acceptable. They are typically not considering the security aspect of every option and helping provide some insight goes a long way. It is not a matter of someone purposely trying to do something insecurely, but rather a situation where someone doesn’t have the exposure. Talk through the different scenarios and why they raise the risk level within the organization or to the clients.

Review any technical controls in place within the organization surrounding plugging devices into the computers. Do you have controls to block these devices? Is that control limited to storage devices? Remember that a USB drive can also be a Human Input Device (HID) which appears not as a storage device, but as a keyboard. These HID devices often bypass limitations on other USB drive types to allow executing code on the system.

Identifying alternative methods means calculating the risk of each one and picking the best choice. As an alternative, the campaign could have been an email campaign with a link in it for users to click. The risk is that people are taught not to click links in emails. Another option could have been to send the mail, but instead of the USB Drive, include a link for the user to type into their browser. It is recommended to use a link that goes to your domain, not a shortened URL. This provides more trust in that the destination is not hidden. Take the time to consider alternatives and the risks for each one.

MongoDBs under attack from ransomware

In recent news, it was identified that MongoDB databases are being exposed on the internet and infected with ransomeware. In a little under a week, the infection count went from 200 to 10,000. That is a quick ramp up.

In this case, misconfigurations may bind the database port to the public interface, while also allowing anonymous access. This combination can be devastating. Doing a quick search on Shodan you may find there are thousands of misconfigured MondoDB servers exposed on the internet.

Like many other software packages, MongoDB has a security checklist available to help minimize this exposure. The checklist covers important steps, such as enforcing authentication and limiting network exposure. I am seeing more packages that are including security checklists, or security guides that are available. If you are installing something new, take a moment to see if there is a guide availble to properly secure the item.

In addition to the security checklist, the creators of MongoDB have created a post addressing the ransomware attacks that are happening. This link points out a few other items to help secure your MongoDB instance. It also points out that the most popular installer for MongoDB (RPM) limits network access to localhost. This default configuration is critical in helping reduce the exposure of these databases.

As time goes on, I expect we will see more improvements made to these types of products that make them more secure by default. As an organization developing this type of software, or devices, think about how the item is installed and how that reflects security. Starting off more secure and requiring explicit configuration to open make the item available will provide much better protection than it being open by default.

If you are running MongoDB, go back and check the security checklist. Make sure you are not exposing the instance publicly and authentication is enabled. Also make sure you are taking proper backups to help recover if your data is manipulated. If you are running other software or devices, make sure to know where they are and determine if they are deployed securely. Check to see if a security checklist exists.

There are lots of exposed MongoDB databases available. Take a moment to make sure yours are not part of that count.


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.