Contact us for your penetration testing needs 1-866-PLYNT-24    |   Contact Us   Plynt UK Website  
Click to get Security Testing Quote

I'm an online merchant

  1. Are these attacks for real? Does anyone get affected really?
  2. As an eCommerce Merchant, what are the threats I'm exposed to?
  3. I use SSL for my login and shopping cart pages. Should I use SSL for other pages too?
  4. I heard the CVV2 code doesn’t increase security these days. Is that true?
  5. How can I track if my mailing list I use for my fortnightly newsletter has been stolen?
  6. All my web pages have SSL enabled. You still think I might be vulnerable to these attacks?
  7. In my product reviews page, I display the email id of the reviewer. But spam bots have been harvesting the mail ids. How can I protect against that?
Are these attacks for real? Does anyone get affected really?

People often wonder if all these attack techniques and exploits are indeed for real. Is anyone really hit by these attacks? Is this all just theory?

While it's unlikely that any company will want to publicize that it's been the victim of an attack, some incidents do get reported in the media. The Webappsec site maintains an incident database of those reported in the media.

As an eCommerce Merchant, what are the threats I'm exposed to?

Here’re ten common threats eCommerce sites have to defend against:
- An adversary steals credit cards and user details
- An adversary manipulates the price of products
- An adversary fakes orders on behalf of other users
- An adversary cancels the orders of other users
- An adversary modifies the shipping address of an order
- An adversary shuts down the online store
- An adversary harvests email ids for spamming
- An adversary resets the passwords of other users
- An adversary gifts himself a gift voucher from another user
- An adversary places two orders for the price of one

I use SSL for my login and shopping cart pages. Should I use SSL for other pages too?

SSL is essential when sensitive data is sent over the Internet, like login details and credit card info. It’s actually most secure to use SSL on all pages. But, that can slow your site down considerably. If you can’t use SSL on every page, here’s an important precaution to take.

Remember, apart from the password and credit card details, there’s another piece of data that should be sent only over an encrypted connection. That’s the token that an authenticated user receives. For the length of a session, that’s as powerful as the password and grants users access to the shopping cart. This token might come in different forms: it’s the "AuthCookie" in .Net, it’s often the JSESSIONID cookie in jsp applications when the session token is also the authentication token. Whichever form it may take, that token should be sent only over SSL.

How do you ensure that? If that token is sent as a cookie (and it most likely is), then set the secure attribute for the cookie. The secure attribute tells the browser to send the cookie only over an SSL connection. There is no easy way to do it if the token’s sent as a query string variable, or hidden variable. [That’s another reason why authentication tokens should be implemented as cookies.]

Since the token will now be sent only on SSL connections, you can’t use the token for your non-SSL pages. So if you need to validate the user or session even from non-SSL pages, you will need an addition (non-secure) token that tracks the user’s session.

To summarize,
- Use different tokens for granting access to non-SSL pages vs SSL pages
- Send the higher privilege token only over SSL connections
- Use the "secure" attribute of the cookie to ensure the token is sent
only on SSL links
- To access non-SSL pages,use the regular token

We discussed protection for session tokens in this Palisade quiz.

I heard the CVV2 code doesn’t increase security these days. Is that true?

CVV2 is the name Visa gives the 3-digit code that appears on the back of credit cards. Mastercard calls it CVC2, Discover and Amex call it CID. In general, they are called Card Security Code (CSC). When a merchant asks a customer for the CSC, it gives an added layer of protection against fraud: only a user with access to the physical card can cite the CSC. At least, in theory.

Of late, the usefulness of CSCs have been challenged. After all, this argument goes, when phishers steal a credit card, they steal the CSC too from the user.

So, what extra protection does CSC give? This argument was well articulated in a Dreamhost blog post.

In defense of CSC, note that not all credit cards are stolen by phishing. Many are stolen directly from billing databases of other merchants. When an attacker compromises the system of a merchant, they get hold of thousands of credit card numbers - but, not the CSC. Visa, Mastercard and others require that merchants never store the CSC codes, that they destroy it immediately after use. So, even if a merchant is compromised, the CSC card would not get into the hands of the bad guys. Thus, when a user enters the CSC correctly, there’s higher likelihood of it coming from the true cardholder.

Wikipedia has more on Card Security Codes.

You might also want to check out Dreamhost’s follow-up post on why they use the codes now.

How can I track if my mailing list I use for my fortnightly newsletter has been stolen?

One way to detect if your mailing list has been stolen is to use Honeytokens.

Create a new mail id at say, gmail or yahoo. Add that email id to your mailing list. But do not give out that id for anything else. The only emails that id is supposed to receive are your newsletters. If you get any other mail, that’s most likely because your mailing list database has been stolen.

To reduce the chance of spammers accidentally guessing the id, use a really obscure, long email id. And, again, remember not to use it for anything else!

For more ideas, check out Lance Spitzner’s excellent introduction to Honeytokens in Securityfocus.

All my web pages have SSL enabled. You still think I might be vulnerable to these attacks?

A common misconception is that SSL is the answer to most attacks.

SSL ensures that the server is who he claims to be, and that the traffic cannot be eavesdropped by anybody else. It achieves this by using a digital certificate to prove the authenticty of the server, and encryption to secure the traffic.

However, SSL cannot prevent an adversary intercepting his own communication with server using freely available web proxy editor tools (e.g. Webscarab, Burpproxy etc.). These tools intercept SSL communication within the adversary’s machine and present editable data to him in plaintext, which can be used to launch several popular attacks.

In my product reviews page, I display the email id of the reviewer. But spam bots have been harvesting the mail ids. How can I protect against that?

You can beat the spam bots from harvesting email ids, and still display it for your "human" users. The technique is to use a javascript to hide the email id from bots.

First, encode the email address you want to display. Write a javascript snippet that can decode the encoded address. On your page, embed that snippet instead of the email address directly. Thus, users see the decoded email address, the bots see the encoded stuff and will not recognize it for what it really is. We use this technique to hide email addresses from bots in Palisade.

And you don’t have to write your own encoding-decoding engine. Here’s a nifty one from Automatic Labs you can use directly. Thank you, guys!


Request a proposal

Our quote contains the best price, the time estimate, and our methodology; and we'll mail you the quote in 24 hrs.


                                                
 
Movable Type Appliance - Powered by TurnKey Linux