Never use JUST the referrer field for verification/authentication purposes. It is supplied by the client, thereby apt to be compromised. Consider it compromised. There are MANY scripts and applets on the web that easily allow malicious users to provide a bogus referrer. We see these types of attacks all the time...
The discussion about doing all the talk with the CC service on your server is the ONLY way to go - never allow the client to go off-site and return - you can't trust anything the client provides you, to include form fields, hidden or not. Create a unique value, call this a session ID, and send it to the client as a cookie or URL. CF can do this for you. Create two more unique values, call this your ticket and ticket value. Send it as a cookie or URL, using the first value as a field name, the second value as its contents. Collect login info from the client via a form, and receive back the cookie or URL ticket id, ticket value, and session ID values. Use JavaScript on the client to encrypt all form contents, in addition to using SSL. Receive the form info, decrypt it. Look up the session ID, ensure the ticket you issued to the client matches the ticket you collected back with the form contents. Using the above you can prohibit all but the more sophisticated bad guy from brute-force attacking your system. You can perform some countermeasures to defeat this more sophisticated bad guy by keeping track of login attempts with a database driven log (flat files won't scale in all scenarios) where you collect IP addresses and login attempts, and timestamp each attempt - allow so many attempts using a given session ID and if it breaks the threshold log the IP as a bad guy. Not much you can do with the IP, as it can be forged by spoofing by those simply looking to DoS you, and given all the proxies in the world (esp. AOL) you're often gonna see different IP's for each HTTP request. But, you CAN log it as a bad guy (just write it once, maybe keep a second value, a counter, for each logged attempt per IP, but don't just stream a list of bad IPs as that can also become a DoS as your database fills up quickly). Run a background script daily, hourly, or whatever to collect the bad IP addresses, lookup the WHOIS owners, and submit an automated "attack attempted by a source on your network" message...only send one message per provider, as you don't want to DoS this effort with tons of email, either. Maybe queue it up to you can review, then send - hate to send a message if it was due to a spoofed attack. >From all the above efforts, you now have a limited sense of trust in the data the client is providing in it's probably not from a malicious user. Still always do input validation, truncate values to the length you're looking for, etc, to ensure they don't provide numbers when you want text, etc. I like usernames to be alphabet lowercase - go to a length of 8, 10, 14, whatever, but truncate to ensure it's not longer, and drop anything that doesn't fit the policy. I like passwords to use alphabet (case sensitive) and numbers, with SOME special characters (drop stuff like commas and other characters that you may have problems with in other applications, and ensure it's a printable character and not some control character (like a 255, or 0, etc.)) - recommend you do all of this validation SERVER-SIDE. You can do some of it client-side, but you're giving away your policy if you do. This would help a bad guy...so don't. The reason you bother encrypting with JavaScript, which obviously the bad guy can reverse as he has the code, is really to just keep the kiddies out...it also prevents sniffers from easily coming across your data if you're not using SSL, or if your SSL connection is attacked with a man-in-the-middle. Tools like dsniff are in wide use - assume they're on your network. You're looking for an onion in security - many layers. If the bad guys have the time and will to shed a few tears peeling your onion, you got bigger problems. In a world of easy targets, you need to be harder than the average...and if they're looking to break into your system then you must have enemies... Once you've got data from the client, do the transaction with the CC service using server-side scripting. Recommend you batch job it, to prevent another DoS. This means you should run a check on your batch load, ensure you're not asking for more than once for the same user, etc. Once you've got verification that the client is good, continue to check the session, ticket, and ticket value, with each request from the client for data (i.e. movie file). Track sessions by time, expire them with a time-out, track the number of sessions per user, generate a daily report for your review on top users. Keep at least the past 3 IP ranges a user comes from (I track by class-B, to allow for AOL and such), do a lookup by domain/country, so you can identify if you see a user coming from Poland, Italy, and the US (for example) to prove a valid ID has been passed out (compromised). I see tons of abuse from overseas...cheap bastards... Defense in depth. Build it into your systems. Assume you're under constant attack. If the above concept is full of holes, let me know - as I'm trying to secure systems just as everybody else is. Build security into your application from the get-go. Lots of audit logs, etc. Generate performance reports, graph them, to identify changes in trends. Do everything you can to secure you system. Good luck. ----- Original Message ----- From: "B Schlank" <[EMAIL PROTECTED]> To: "CF-Linux" <[EMAIL PROTECTED]> Sent: Sunday, January 27, 2002 1:43 PM Subject: Re: Preventing Cheating On Payment Systems > Quickie: > > You can use .htaccess to prevent direct linking to your movie by using the > RewriteCond to check the referrer. > If it's not in your domain, you can use a RewriteRule to send them > somewhere else. > > This works for apache, but keep in mind that the referrer is not always > dependable. > > -- B > > > > > At 04:26 PM 1/27/2002 +0000, you wrote: > >Sorry, further note, if you're not happy with your server having to do that > >for every payment > >make the process asynchronous, have another batch process read your database > >and then do the http stuff for you. Setup a scheduled template or write a > >'lil perl script to do it. Then say once there payment has been done > >they'll get an email. > >little perl daemon's nice for that, or tcl for that matter (insert fav > >scripting language here ;-) > > > > > >At 18:15 27/01/2002 +1100, you wrote: > > >I'm writing a small CF application for a customer. The concept > > >is quite simple. A visitor comes to the website and pays $10 > > >via an internet CC payments company. The payment of $10 allows > > >the customer to view a movie. > > > > > >The implementation seems to have a flaw. The internet CC payment > > >company provides a CGI which receives information via hidden > > >input fields. The hidden fields contains details identifying > > >who the payment is to be credited to, the amount and the > > >URL to call if the transaction is completed succesfully. > > > > > >I've been wondering how to clever people from simply calling > > >the sucessful transaction URL to view the movie, thereby > > >bypassing the CC payment transaction. > > > > > >All of the ways I've though of for preventing people directly > > >calling the succussful transaction URL have the problem that > > >they are easy to work around. > > > > > >I'd appreciate peoples input on the best approaches to > > >overcoming the problem using CF. > > > > > >Regards. Paul > > > > > > > > > ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com ------------------------------------------------------------------------------ Archives: http://www.mail-archive.com/cf-linux%40houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_linux or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
