homepage Welcome to WebmasterWorld Guest from 54.211.231.221
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld
Visit PubCon.com
Home / Forums Index / WebmasterWorld / Ecommerce
Forum Library, Charter, Moderators: buckworks

Ecommerce Forum

    
ID Thieves Target Smaller Businesses
Small businesses offer fewer victims, but they are often a softer target
shri




msg:3101164
 11:09 pm on Sep 28, 2006 (gmt 0)


While public attention has remain fixed on a series of high-profile data losses or database breaches at federal government agencies, large corporations and universities, experts who study financial fraud say hackers increasingly are targeting small, commercial Web sites.

From this article [washingtonpost.com] in the Washtington Post.

What I find interesting is the direct attack on some of the hacker testing services.

Also, goes back to a posting I made a few weeks ago in the supporters forum -- are you ready for Christmas?

 

shri




msg:3101172
 11:16 pm on Sep 28, 2006 (gmt 0)

So, to start of, what can you do?

At the very minimum upgrade your software to the latest versions from the vendors. Include everything from the operating system to apache and php to the various modules you might have in your store.

Just last week we found an unpatched phpads on a server that was abused.

Also, one thing I've not been too sure of, we do not store credit card information. The only time a user enters a credit card is when they hit worldpay / paypal type third party screen?

Is it then a reasonable assumption that the credit card information is a little bit more secure than it would have been in our hands?

httpwebwitch




msg:3101319
 1:56 am on Sep 29, 2006 (gmt 0)

the credit card information is a little bit more secure

safe assumption. In order to store credit cards yourself, you need to meet some very strict security standards, both digital, physical, and personal.

If you're using a home-made shopping cart that stores credit cards in a database, and you haven't heard of these strict guidelines (required by the credit card companies), then you're probably doing it wrong and you're asking for trouble.

Bewenched




msg:3101332
 2:19 am on Sep 29, 2006 (gmt 0)

You should never store a credit card number, expiration date or verification number in a database connected to the internet. If you absolutely have to get the number again after the transaction you can call your processing bank and retrieve it.

shri




msg:3101429
 5:51 am on Sep 29, 2006 (gmt 0)

>> In order to store credit cards yourself, you need to
>> meet some very strict security standards, both
>> digital, physical, and personal.

Which is why we opted for a less integrated approach. I did not want the liability of a customer being ripped of.

We store name, address and phone number. Thats it ...

Which makes me wonder, at what stage of the transaction does the information get compromised for these small businesses? Are they storing credit card information?

jamie




msg:3101450
 6:25 am on Sep 29, 2006 (gmt 0)

thought-provoking post shri thanks - just going to check my phpads!

the other side to this is where they use the credit cards. we have just identified a string of bogus orders from several months ago. we are a small e-commerce site and although i wouldn't say we are a soft target, i've realised there are plenty more security checks we should be doing at the moment of purchase. pretty alarming.

Vamm




msg:3101638
 10:17 am on Sep 29, 2006 (gmt 0)

shri: Let's assume the backend (who actually processes the credit card number) is a separate company (and a separate site). The backend processor is typically a high profile (and tough) target, so we forget about attacking it for now.

I see two scenarios possible:

1. The "target" site collects data, including the card number (and CVV) and forwards them to the backend using some sort of script.
The attack is to modify the "target" scripts so that a carbon copy of the data is sent to the attacker.

2. The "target" site does not collect data itself. It rather provides a link to the backend, which prompts for data, then handles the rest of the processing.
In such a case the attacker would just replace the link to point to the fake backend. The fake backend captures the data and either bails out with an error message (database down please check back later) or forwards the data to the real backend processor (so the transaction finally completes).

There are multiple other technical considerations, but I think I've outlined the overall idea.

Corey Bryant




msg:3101763
 12:32 pm on Sep 29, 2006 (gmt 0)

There are a lot of companies that will do a free scan of your site and to become CISP compliant is around $400 a year. A little over $1 a day. But a lot of companies cannot afford $400 up front unfortunately.

In essence though, it is like insurance. It does help to protect you. It will let you know if there are holes in your software and on the server.

Getting CISP compliant is a process. It is just not about the servers, about the software, about the transaction, etc. It is about the entire process. And it is one solution.

Hosting companies can say they are CISP compliant but if you put a script on there - it might not be compliant.

Shopping carts can be CISP compliant, but if you choose a hosting company that might not be secure, then you are not CISP compliant.

-Corey

ssgumby




msg:3101823
 1:11 pm on Sep 29, 2006 (gmt 0)

This is quite an interesting article. Let me pose a few questions to you all.

How many of you encrypt sensitive data stored in your database? Sensitive data is name, email, address, phone.

I wont ask about credit card as I know none of us are storing this. ;)

How many encrypt the user/pw to the database in a separate file outside of the web application?

How many use a strong encryption like AES?

How many have a regular security review in place to change passwords on a regular basis (every 30 or 60 days)?

How many validate input data from their forms for malicious characters?

How many know what web server they are running on and what service pack this web server is on?

These are just a few questions we all should be asking ourselve as a FIRST step towards security.

It is possible to prevent 99% of all attacks .. I wont say 100% because there are absolute freakishly intelligent people who are determined to get in and no matter what we do they WILL find a way around it given time.

ccDan




msg:3101976
 3:06 pm on Sep 29, 2006 (gmt 0)


2. The "target" site does not collect data itself. It rather provides a link to the backend, which prompts for data, then handles the rest of the processing.
In such a case the attacker would just replace the link to point to the fake backend. The fake backend captures the data and either bails out with an error message (database down please check back later) or forwards the data to the real backend processor (so the transaction finally completes).

If the hacker was smart, he would forward the data to the real backend processor so that the transaction completes. A small business could potentially notice within a couple days (or even the same day) if their account is not being credited for orders that have been placed.

But, if the transactions continue to go through normally, it could be months (or longer) before the business ever realizes what's happening.

The best option might be for consumers to use credit cards that will allow you to get a single use number and then use that to make purchases. That way, the hacker would have to process the card first, and then the real transaction will fail, clueing in the business. If the hacker waits, his charge won't go through. Of course, that means that it has to be made easier for consumers to get single use credit card numbers.

shri




msg:3102904
 1:35 am on Sep 30, 2006 (gmt 0)

>> In such a case the attacker would just replace the
>> link to point to the fake backend.

Wow .. had never thought about that one.

So, somehow, by either changing our shopping cart (easier) or changing the hosts file they would be able to redirect our call back to worldpay / paypal to their own site.

Vamm




msg:3103397
 2:47 pm on Sep 30, 2006 (gmt 0)

Certain payment processors do not allow tranmission of order data via script. In such a case, no straightforward routing of the data to the backend exists.

Basically, one analyzes the possible attack vectors by listing elements (principal elements; atoms) of the entire order process. Typically, every element may be attacked. On top of that, typically at least two conceptually different attack vectors exist for any given element.
In case of URL redirection, the attacker may either target the webserver (to modify the HTML page on server), or the client machine (to modify the HTML page e.g. in the browser cache; or to provide fake DNS as suggested).

You may also want to search for "phishing", which is not the exact thing we are discussing but is related.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Ecommerce
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved