Block PayPal phishing with htaccess

Can I block POST requests

[csherrill]

I manage a couple sites for family and friends. One of them sells a book and accepts payment through PayPal. A couple months ago I noticed several entries per day like the one below. I immediately emailed PayPal and got a 'We received your email' reply, but nothing helpful.

86.109.163.26 - - [08/Oct/2007:22:45:54 -0500] "POST /https://www.paypal.com/cgi-bin/webscr HTTP/1.1" 302 299 "http://www.domain-name.com/book.html" "Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686)"

All of these come from Europe and Asia and from a variety of IP's. The most frequent is bbtec.net

I renamed the page with the PayPal button, changed the button graphic to a .gif hosted locally instead of on PayPal and made the new page no cache, no follow and no index. With htaccess I've tried blocking ips and ip ranges with <Files *> and with <Limit GET POST>, but that doesn't work. The user agents on these requests change frequently so I can't filter those. Yesterday I tried to block POST requests for PayPal from any page that's not the new book page, but that failed too.

# Deny PayPal scammers from old book page
rewritecond %{REQUEST_URI} ^https://www.paypal\.com/cgi-bin.*$ [NC]
RewriteCond %{HTTP_REFERER}!^http://www.domain-name\.com/newbook\.html [NC]
RewriteRule .* - [F]

If I'm reading the log correctly, the PayPal page is the REQUEST_URI and the old book page, book.html, is the referrer (or referer). These aren't reversed for a POST request are they?

Has anyone else run into this and do I even need to worry about it?

Thanks.

[jdMorgan]

The pattern in the first RewriteCond is missing a leading slash, and contains some unnecessary regex at the end. I'd recommend:

# Deny PayPal scammers from old book page
RewriteCond %{REQUEST_URI} ^/https://www\.paypal\.com/cgi-bin [NC]
RewriteCond %{HTTP_REFERER} !^http://www.domain-name\.com/newbook\.html
RewriteRule .* - [F]

If that works, you might also try this shorter version:

# Deny PayPal scammers from old book page
RewriteCond %{HTTP_REFERER} !^http://www.domain-name\.com/newbook\.html
RewriteRule ^https://www\.paypal\.com/cgi-bin - [NC,F]

Also, in case the requested URI varies (now, or later in an attempt to bypass your code), you could "widen the net" a bit by changing the URI pattern to:

https?://(www\.)?paypal\.com/cgi-bin

to allow for both SSL and non-SSL requests as well as both the www and non-www paypal domains.

Jim

[csherrill]

Wow. Thanks very much, Jim.

Cutting and pasting without understanding frequently gets me in trouble - I'll research why the slash has to be there and try the long version first and keep the shorter, wider one commented for future reference.

[jdMorgan]

In .htaccess, the URL-path given by %{REQUEST_URI} always has a leading slash, while the URL-path 'seen' by RewriteRule does not.
In httpd.conf or other server config files, both will have the leading slash.
The difference is due to the fact that .htaccess is a per-directory config file, and the path to that directory is removed so that .htaccess RewriteRules can be location-independent.

Jim

[csherrill]

Thanks again. I found another explanation, but yours is clearer.

If you're in an explaining mood, can you tell me (and future readers) why this:

<Files *>
order allow,deny
allow from all
deny from 86.0.0.0/8
etc...

doesn't seem to block these POST requests?

[csherrill]

Unfortunately that didn't work. I checked the logs this morning and there are still several POST requests for PayPal that get a 302 code.
I'll try 'wider' Rewrite you suggested.

[jdMorgan]

Note the 302-Found response; Your server is redirecting this request.

If the "wider" pattern code doesn't work, try this more-general solution, replacing "example.com" with your domain:

# BLOCK attempts to use our server as a proxy, but allow absolute URIs
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /?http:// [NC]
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ /?http://([^.]+\.)*example\.com/ [NC]
RewriteRule .* - [F]

Jim

[edited by: jdMorgan at 12:38 pm (utc) on Oct. 10, 2007]

[csherrill]

Thanks again. I'm not confident the wider test will be any more effective than the original that uses the same criteria. I'll try this new method and report back tomorrow (when the logs are available).

Reading [w3.org...] makes me think that the 302 code is the server equivalent of saying, "Yes, there's someone here by that name, but he's not coming to the phone."

I'd prefer to not give phishers anything... except maybe a virus, but I don't think htaccess can do that <grin>.

[jdMorgan]

I use that recently-posted code on many sites. As long as it gets executed, it should take care of your problem.

Jim

[csherrill]

It must not get executed because I'm still getting these POST requests.

I've left the code you gave me active and I've added

# Block PayPal Phishers
RewriteCond %{THE_REQUEST} ^POST\ /https://www\.paypal\.com/cgi-bin/webscr\ HTTP/1\.1
RewriteRule .* - [F] 

because all the unwanted requests are identical.

Thanks again for all your help.

[jdMorgan]

Sorry, I forgot to cover the "https" bit:

# BLOCK attempts to use our server as a proxy, but allow absolute URIs
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /?htt[b]ps?:[/b]// [NC]
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ /?htt[b]ps?:[/b]//([^.]+\.)*example\.com/ [NC]
RewriteRule .* - [F]

What server response code are you seeing in the access log for these requests?

Jim

[edited by: jdMorgan at 1:39 pm (utc) on Oct. 11, 2007]

[csherrill]

Ah, I didn't catch the missing 's' either. I've edited those lines.

I'm getting 302 plus another number, 299, that I think is the file size.

This site runs a classifieds cgi script, too. Because of Chinese spammers, I don't allow direct access to that script. Visitors have to be referred (refered) by another page on the site. In the logs I see the attempts at direct access to the script page as 302s as well. Sometimes I get 10 or 12 of these in a row, indicating that the security is working and the bots hit their limit and leave.

I may be overreacting to the PayPal requests - perhaps I should just add a don't log code, [L] I think, and forget about them.

[jdMorgan]

Logging cannot be controlled by .htaccess. You can set it up using mod_log_config in httpd.conf though. The function of the [L] flag in mod_rewrite is a completely different thing.

Jim

[csherrill]

Oops. I've been looking at so many tutorials, I must have conflated a couple.

Still no luck getting rid of these. In fact, they're getting more frequent. I may have found a clue though.

I temporarily blocked all POST requests. With the block in place I could not submit html forms to a cgi script, but I could still use the PayPal button. This made me think the POST is handled by PayPal's servers, not mine. Using the LiveHTTP plugin for Firefox confirms this. It lists the host as www.paypal.com

What I can't figure out is why my server is logging these if they're events on the Paypal server and how to prevent my server from responding to anything but a legitimate request. What my server seems to be broadcasting is that there is a PayPal connection, but is temporarily unavailable. I'd much prefer that it respond that it's gone, it is no more, it has ceased to be, it is an ex-parrot.

This may be something that has to be plugged on Paypal's end, but so far they're not responsive.

[jdMorgan]

Basically, it appears that your server is forwarding (or possibly proxying) these requests to the PayPal server.

Have you asked your host to look into this? They may be able to do something at the config level (or with a firewall) so that these requests will join the choir invisible and begin pushing up daisies... ;)

Jim

[csherrill]

Success! I checked the logs this morning and there isn't a single stray POST request and the PayPal button stills works.

I made two changes to the htaccess code so I'm not sure which made the difference. The first RewriteRule was changed to G from F and L was added to both.

# Block PayPal Phishers
RewriteCond %{THE_REQUEST} ^POST\ /https://www\.paypal\.com/cgi-bin/webscr\ HTTP/1\.1
RewriteRule .* - [G,L] 

# BLOCK attempts to use our server as a proxy, but allow absolute URIs
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /?https:// [NC]
RewriteCond %{THE_REQUEST}!^[A-Z]{3,9}\ /?https://([^.]+\.)*www.example\.com/ [NC]
RewriteRule .* - [F,L] 

Thanks again, Jim, for all your help. Hopefully this will help others, too.

[g1smd]

You probably don't need the www in the URL, otherwise it might not block things correctly.

You're also only checking for https requests, not for http, now that the? was removed from the code.

[g1smd]

# Block PayPal Phishers
RewriteCond %{THE_REQUEST} ^POST\ /https?://www\.paypal\.com/cgi-bin/webscr\ HTTP/1\.1
RewriteRule .* - [G,L]

# BLOCK attempts to use our server as a proxy, but allow absolute URIs
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /?https?:// [NC]
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ /?https?://([^.]+\.)*example\.com/ [NC]
RewriteRule .* - [F,L]

[edited by: jdMorgan at 8:13 pm (utc) on Oct. 13, 2007]
[edit reason] formatting [/edit]

[csherrill]

Well $%@$%%! They're back. I don't know why there weren't any POST hits for one 24 hour period, but evidently it wasn't htaccess.

I don't have access to httpd.conf so I contacted my host to ask if there's anything they can do.

In the meantime I'll try removing the www as per g1smd.

[csherrill]

My host is still working on this, but in the meantime I imported the log for yesterday into Excel to make it easier to sort.

We had 36 of these Paypal POST requests. 25 of them came from the same IP 77.91.227.181 but with 12 different UA's!

That IP belongs to WEBALTA / Internet Search Company (77.91.227.128 - 77.91.227.255) which is purportedly a Russian search engine. Why would a legitimate search engine disguise its user agent and only go after a PayPal link? I've added that specific IP to my 'deny from' list.

Of the remaining 9 POST requests, 4 were given 410 - It's Gone codes instead of 302's.

We'll see what my host comes up with.