I would assume that you have a rationale as to why a user behind a proxy should be less trustworthy than another user not behind a proxy.

For example, in both my companys network and my home network, I have proxies that shield (if I chose to) my browsers from the direct contact with the outside - so I'm not sure, how much trust you should be putting into a recommendation given by a user from behind a proxy.

I see two possibilities of how to detect a proxy :

1. building a list of known IP adresses for big proxies (AOL proxies for example)
2. Looking at the X-Forwarded-For or the X-Client-IP header could also indicate, that this user is behind some proxy.

Personally, I would guess that "people behind a proxy" is a quite unsound criterion for "people much more likely to commit fraud", and you will most likely lose a part of your business (whatever it is you sell) due to it. Unless you have hard numbers on the part of your customers behind proxies and the number of fraudulent transactions, I wouldn't block proxies.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web
[download]

I guess your thinking is that fraudsters are likely to access your site via proxies to hide the real originating IP. While that is most likely true, the assumption that someone using a proxy is therefore most likely a fraudster, is not a sound assumption.

Don't do it.

I don't think you want to detect if they are behind a proxy, because there are many legitimate reasons for being behind a proxy (I'm using one right now).

However, you may want to see if they're behind an open proxy (a proxy that will allow anyone to relay a connection through it). If that is the case then they are more likely to be trying to hide the true origin of their request, and open proxies are generally run by people who either didn't mean for them to be open or just don't care, so you're not likely to be able to track down someone who uses one.

To detect that, you could attempt to connect to several commonly used proxy ports on that IP address (see the IANA ports assignment page for a good starting point), then if the connection is successful, deny their request. One disadvantage that this would have is that some people may be running intrusion detection systems that see this as an attack on their system.

Another option would be to use an already compiled list of open proxies (which is probably how they found the open proxy they're using). There are good ones at http://www.openproxies.com/ and http://mikhed.narod.ru/download/lists/goodproxy.txt.

I am writing a little order form for my site, I have been getting a fairly large amount of suspicious orders and I'm trying to get ways of minimizing the risk of fraud.

If you are already suspicious, then something is slightly wong (or at least interesting). Think hard about your suspicions, write them down, design a solution then automate. Obviously carbon units are very good at fuzzy logic, so creating broad rules that raise exceptions you (the carbon unit) have to filter may be the best method..

people not behind proxies have a better chance of being trackable back to a specific account at a specific time. either dialup, static, or dynamic is more likely to have assignment logs somewhere that can be investigated. tracking back through a proxy is like getting blood from a turnip.

it's like not letting people wearing ski masks into banks. except some out there have the masks sewn onto their face by their ISP.

I'm also behind a proxy at home, because most ISPs in Australia do it that way to save money, simply to cache the commonly-requested pages and so on.

If you refuse to sell me stuff just because I'm behind a proxy, you've lost me as a customer. If you choose that route, and I strongly suggest you don't, then I hope to god you're going to tell me so, and not leave me hitting SUBMIT buttons and getting "there seems to be a problem, try again" errors.

I think this question is a case of jumping the gun. Your problem is you're getting fraudulent and/or suspicious orders. You've already jumped to a solution and you're asking for help with that solution.

I humbly suggest that you go back a step. Problem: dodgy orders. Describe the symptoms. Then ask, what are the solutions?
--
“Every bit of code is either naturally related to the problem at hand, or else it's an accidental side effect of the fact that you happened to solve the problem using a digital computer.” M-J D