2

I'm setting up a small code-hosting web site, in the vein of github or bitbucket. I would like to allow users to specify an arbitrary URL from which my site's server will initially clone their repository. I'm using mercurial, so cloning essentially just means negotiating a simple HTTP-based protocol between the client (my server in this case) and the host (the URL that the user has provided).

I don't know all of the details of the mercurial protocol, but it involves making some GET and POST HTTP requests, and specifying some query parameters on the user-provided URL. Other than the URL the user should not have any control over what requests are sent from my site to the URL they specify.

If successful, the interaction with the provided URL will produce a set of files, which will be served from my site, possibly to other users, but not directly, with the exception of images. In other words, if it's an image file, I will serve it, but otherwise it will only be viewable as escaped text.

Are there any security implications I should be aware of with this? I understand I can't serve arbitrary user-provided HTML, Javascript, Flash, etc., and unless there are issue serving arbitrary images that I'm not aware of, I think the serving part should be fine. I'm concerned more about interacting with arbitrary URLs that a user provided.

Improve this question

1 Answer 1

Reset to default
2

are issue serving arbitrary images that I'm not aware of

There are actually - Gifars which are a GIF image and JAR file combined.

Regarding your original question, you should validate the URL to check it is a valid format for a http or https URL (i.e. not FTP or another protocol), and you should check that the domain resolves to an external website (i.e. that an attacker hasn't entered an internal IP such as 192.168.1.1 or that DNS resolves to an internal IP which could probe your internal network infrastructure). Make sure that your HTTP request goes to the same IP as the one your validation uses. Also you should lock down your server environment as much as possible so that only the internal servers necessary are contactable on your network.

You should make sure that either HTTP redirects are not followed, or if they are you should execute the same validation on each redirect in the chain. You should also check that there are no redirect loops that could DoS your system, by enforcing a maximum redirect count.

Also you should be aware that attackers could use your service as a proxy. For example, sending SQL injection attacks to other internet servers which would report your service's IP address as the source. You should make sure you log all requests against user IP and account. You could also rate limit based on this data to prevent one user/IP making too many requests, in which case you could validate with a CAPTCHA.

Improve this answer
3
  • Just a quick question about GIFARs, because I'm having trouble understanding the information I find about them: it's only a vulnerability if the attacker can also place an applet tag on the site, is that right?
    – brianmearns
    Commented Mar 11, 2014 at 12:21
  • 1
    @sh1ftst0rm No, the attacker can place the <applet> tag on their own site, but would need to entice the visitor to visit that site while logged into yours. The origin for a Java applet is the hostname of the website where the applet is served from. If the <applet> tag points to http://www.example.com/my_gifar.jar, the applet’s origin is www.example.com
    – SilverlightFox
    Commented Mar 11, 2014 at 12:47
  • Ah, ok, that's a key point I was missing. Thanks a lot for clarifying!
    – brianmearns
    Commented Mar 11, 2014 at 13:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .