Protecting Your Store from Cross-site Scripting Attacks

login-form-570x370-1-6775114

Gaining access to login data such as a user name, password, or a token is a common target of cross-site scripting attacks. If a thief can steal those, he can access a user’s account info.

Security is vital for every ecommerce site. A breach of customers’ payment data or personal information could kill a business.

But an ecommerce site has other security risks, too. A common one is cross-site scripting. Any site that uses forms, search, or even an administrative backend is vulnerable — essentially every online store.

Any site that uses forms, search, or even an administrative backend is vulnerable…

There are many forms of cross-site scripting, or XSS. It occurs when an attacker adds code to a web page, and the code then runs in the browser of an unsuspecting user, causing harm. Ninety-nine percent of the time this code is JavaScript.

A web page is vulnerable to an XSS attack when it doesn’t remove the user input correctly. For example, if a comment form allows someone to add HTML, an attacker could post a comment that includes the attack code.

The common way to do this is to add a JavaScript source link using the script tag. This will cause the browser to download and run the JavaScript, which could then steal the user’s data.

Targets of XSS

Authentication data such as a user name, password, or token is a common target. If an attacker can steal those, he can log in as the user with full access to the user’s account.

The attacker could, as an example, change the shipping address for a recurring order or use a card on file to make fraudulent orders. Once the attacker logs in, it becomes very difficult to tell the difference between the legitimate user and the attacker.

One way to detect is to track the usual location of a user and compare it to the attacker. If the user logs in from Texas and there’s suddenly many logins from another state or country, that’s a sign that the account has been hacked.

XSS attacks that steal an administrator’s authentication data are even more critical. With administrative access, an attacker could, as examples, create hundreds of fraudulent orders, change how payment receipts are routed, or delete every piece of data in your store.

This is the worst-case scenario. It’s also a reason to have strong security practices for administrator accounts.

XSS attacks that steal an administrator’s authentication data are even more critical.

Your store collects other data, such as address and order info. They may not be as critical as payment data or login data, but it could cause a major customer service issue nonetheless if breached. That’s especially the case if the customer is a celebrity. Disclosing her home address or what products she ordered could produce a scandal.

Preventing XSS Attacks

Preventing XSS attacks isn’t easy. All forms of user input could be a security risk. With the rise of user-generated content, the web is much more interactive. Thus XSS attacks are common.

A good way to prevent XSS attacks is to clean up all data entered by a user. It’s called “input sanitizing.” It removes or renders harmless any HTML or JavaScript from a user. Many code libraries and ecommerce platforms do this by default.

The problem is that input sanitizing limits what a rightful user can enter. It could, for example, restrict a user from bolding certain words in a blog comment or linking to another page.

Allowing only a few seemingly safe tags could be risky. Even non-JavaScript tags such as a link or image could trigger a carefully crafted XSS.

Many XSS attacks will try to steal a user’s authentication cookies. There’s a simple, built-in protection called “HttpOnly” that prevents JavaScript from accessing cookies. It’s an option on the cookie that must be set. It will block your own JavaScript from using it, too, but it’s a simple way to add another layer of protection.

How Vulnerable?

XSS can attack most any ecommerce site. It doesn’t matter if it’s running open source, a hosted platform, or purchased software.

Open source systems are usually quick to fix an XSS or any other security problem. Many will quickly release a new version. Minimize your risk by keeping your systems updated.

Hosted platforms also address XSS issues promptly. Many times merchants won’t know a security hole was fixed as their sites were automatically upgraded. A downside of hosted platforms is that the same software usually powers every store. Thus an attacker could discover access to one store and then attack every other site on the platform.

Commercial software security varies. The good ones will immediately release a new version once a security problem is fixed. But a merchant could be on the hook for the upgrade.

XSS vulnerability also applies to plugins, apps, and third-party systems. If you’re using a popular app, it will likely be upgraded and secured quickly in the event of an XSS attack.

Finally, if your store uses custom code, all of this falls on you and your team. There are many common practices for developers to audit your code and secure it. Even then, you could still scramble occasionally.

Source