I sent the message you received as a follow up to an original message that for some reason was never posted. In it I described a simple system to deal with people taking advantage of hidden fields in CC processing forms. The followup was an add-on to my original message.
-- B At 08:34 PM 1/27/2002 -0500, Rob Patrick wrote: >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 > > > > > > > > > > > > > > ______________________________________________________________________ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. ------------------------------------------------------------------------------ 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.
