6

I took a look at my logs and found out that earlier this year, random computers made a request to resources and my log recorded it as follows:

"GET http://testp3.pospr.waw.pl/testproxy.php HTTP/1.1"

I also received a few others that are similar except that testp3 is testp1 and testp4 instead. So I checked the URL and it returned my IP address.

I'm tempted to make a module that stops requests starting with http:// from accessing any part of my server (even before mod-rewrite kicks in) because I like my server fast.

Because my server is shared amongst a large number of clients, I need to know the following before I feel I can establish a solid answer to my question:

  1. Are there cases where merging a URL within a URL is actually necessary? I don't want to block the inner http:// only to have a valid client complain that his system doesn't work.

  2. Do requests like this on an apache server actually cause the server to connect to the inner URL requested (such as: http://testp3.pospr.waw.pl/testproxy.php)? If so, then I feel blocking will gain me both speed and lower bandwidth costs.

So block, or no block, and why?

P.S. I'm not asking this to gather opinions, I'm asking for a good answer to help me save bandwidth, improve speed and maintain client satisfaction.

Improve this question
5
  • 3
    For the record: I suggest blocking any URI that has http: in it. It is either an XSS or a bad bot. Unless your site requires that http: be passed as a value for a form or API, it would pay dividends blocking some basic things including this. BTW- I am becoming a big fan lately of recommending not blocking, but redirecting back to the requester. If enough of us do this, these problems would mostly resolve itself. Just make sure you create your regex(s) correctly before redirecting back.
    – closetnoc
    May 1, 2015 at 16:49
  • Well it's going to be more involved than regex. I'm actually going to make an apache module that will do this.
    – Mike -- No longer here
    May 1, 2015 at 17:08
  • 1
    The absolute URL is required when making requests to proxies (as the URL suggests) - but I guess you're not providing a proxy service? However, RFC2616 states: "To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies."
    – MrWhite
    May 1, 2015 at 17:41
  • 1
    @w3d I have only seen http: in XSS attacks and badly formatted script kiddie XSS attacks. You are right of course, but in 8 years, I have never seen a valid case in my log files. I have been blocking http: for all of that time. An evaluation of then sites needs is in order first of course before doing anything.
    – closetnoc
    May 1, 2015 at 20:39
  • 1
    There are many security products such as ModSecurity and some others that may be easier on you... but if you write your own, let me know. I was going to write some features that I wanted to make native to Apache- compiled in- that could help. But who has the time??
    – closetnoc
    May 1, 2015 at 20:41

1 Answer 1

Reset to default
2

They are just scanning the network for open proxy. Your server is safe. But better report them to their ISP before there is a victim.

Improve this answer
1
  • 1
    Could you please elaborate? "I don't understand what is scanning the network for open proxy"
    – IAmJulianAcosta
    Jul 2, 2016 at 1:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.