URL redirect may cause security problem

[misterpoesy]

• Gitea version (or commit ref):1.6.1
• Git version:
• Operating system:Windows server 2008 R2
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

try this url:
curl -I http://mygitserver:3000//google.com/..
HTTP response header:

HTTP/1.1 302 Found
Date: Fri, 04 Jan 2019 06:51:21 GMT
Content-Type: text/html; charset=utf-8
Location: //google.com/../

response body:

<a href="//google.com/../">Found</a>.

I can redirect to google.com through mygitserver:3000. This is dangerous!

Can any configuration prohibit this problem?

Screenshots

[0x5c]

It would probably be of more usefulness if your config (the relevant parts) was included

[zeripath]

Hmm... This doesn't happen on try.gitea.io which is on master.

$ curl -i http://try.gitea.io//www.google.c
om/../
HTTP/1.1 302 Found
Location: https://try.gitea.io:443//
Date: Sat, 05 Jan 2019 23:08:16 GMT
Content-Length: 5
Content-Type: text/plain; charset=utf-8

Found

$ curl -i https://try.gitea.io//www.google.
com/../                                                   
HTTP/1.1 302 Found
Content-Length: 24
Content-Type: text/html; charset=utf-8
Date: Sat, 05 Jan 2019 23:13:05 GMT
Location: /

<a href="/">Found</a>.

I'll check out a 1.6 version tomorrow. Could you check from your end too and take a look at the git log between since 1.6 to see if there's an obvious commit that would fix this. In any case, Version 1.6.3 is the now the mainline version for gitea 1.6 and I'd really recommend updating to it - especially if you allow auto sign-up and repository creation.

As an aside I'm not sure that it's really normal practice to put links in http 302s though - so that might need to be changed.

[0x5c]

Giving a link in a 302 response is the required behaviour according to the RFC
https://tools.ietf.org/html/rfc7231#section-6.4.3

[zeripath]

I meant that the body of the response contains an HTML link - rather than being empty or containing the word Found

[0x5c]

Oh right, does not seems good indeed.

[zeripath]

OK, running v1.6.1 on my box I can't replicate this issue immediately OOTB. What are your settings in app.ini ? Are you running over ssl? Are you using REDIRECT_OTHER_PORT?

[misterpoesy]

this is my log of version info:

2019/01/08 09:11:07 [I] Gitea v1.6.1 built with: bindata, sqlite

request log:

[Macaron] 2019-01-08 09:11:27: Started GET //google.com/.. for 192.168.1.100
[Macaron] 2019-01-08 09:11:27: Completed GET //google.com/.. 302 Found in 26.6007ms

I try this request in Google Chrome, IE, Edge, it finally redirect to http://mygitserver:3000//, but in firefox, it really redirect to google.com.

EDIT:
my configuration:

APP_NAME = xxxx
RUN_USER = Administrator
RUN_MODE = prod

[database]
DB_TYPE  = mysql
HOST     = localhost:3306
NAME     = xxxx
USER     = xxxx
PASSWD   = xxxx
SSL_MODE = disable
PATH     = data/gitea.db

[repository]
ROOT = E:/gitea-repositories
DEFAULT_PRIVATE = private
PULL_REQUEST_QUEUE_LENGTH=9999
FORCE_PRIVATE=true

[repository.upload]
ENABLED       = true
TEMP_PATH     = data/tmp/uploads
ALLOWED_TYPES = 
FILE_MAX_SIZE = 300
MAX_FILES     = 10

[server]
SSH_DOMAIN   = xxxx
HTTP_PORT    = 3000
ROOT_URL     = http://xxxx/
DISABLE_SSH  = true
SSH_PORT     = 22
OFFLINE_MODE = false

[admin]
DISABLE_REGULAR_ORG_CREATION = true

[mailer]
ENABLED = false
HELO_HOSTNAME = 
HOST = 
FROM = 


[service]
REGISTER_EMAIL_CONFIRM = false
ENABLE_NOTIFY_MAIL     = false
DISABLE_REGISTRATION   = true
ENABLE_CAPTCHA         = true
REQUIRE_SIGNIN_VIEW    = true

[picture]
DISABLE_GRAVATAR        = true
ENABLE_FEDERATED_AVATAR = false

[cache]
ADAPTER=memory
INTERVAL=3600

[session]
PROVIDER = memory

[log]
MODE      = file
LEVEL     = Debug
ROOT_PATH = xxxx

[security]
INSTALL_LOCK   = true
SECRET_KEY     = xxxx
INTERNAL_TOKEN = xxxxx
MIN_PASSWORD_LENGTH = 10
LOGIN_REMEMBER_DAYS = 1

[0x5c]

I just tested your original curl example on my instance, and I get a 404

root@GLaDOS:~# curl -I http://domain.tld//google.com/
HTTP/1.1 307 Temporary Redirect
Content-Type: text/html; charset=utf-8
Location: https://domain.tld//google.com/
Date: Tue, 08 Jan 2019 02:35:47 GMT

root@GLaDOS:~# curl -I https://domain.tld//google.com/
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8
Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
Set-Cookie: i_like_gitea=[cookie]; Path=/; HttpOnly
Set-Cookie: _csrf=[cookie]; Path=/; Expires=Wed, 09 Jan 2019 02:36:10 GMT; HttpOnly
X-Frame-Options: SAMEORIGIN
Date: Tue, 08 Jan 2019 02:36:10 GMT

Edit:
My Gitea instance is running 30560b0 (1.6.3), on Docker :1
My box on which I used curl is running Ubuntu 16.04

[misterpoesy]

@0x5c
you should add .. after //google.com/. Try this curl -I https://domain.tld//google.com/..

[0x5c]

I also tried with the dots, which got the server to respond according to the standards:
Considering the .. as the parent of the google.com/ directory, which happens to be /, which exists, thus responding with a 200 and serving the welcome page.

[misterpoesy]

I just downloaded the latest release from https://github.com/go-gitea/gitea/releases/download/v1.6.3/gitea-1.6.3-windows-4.0-amd64.exe, and run in empty folder.

I tested in three machine. Window 10 Professional is OK, but Windows 7 and Windows Server 20008 R2 still exist.

Win 7 & 2008R2:

Windows 10 Professional:

[0x5c]

That's weird

[zeripath]

Ok. Two things come to mind:

• Have you actually run the install page yet? Because if not, please run it and recheck. If once you run that this issue goes away then this is far less important as there are much bigger issues with having a non-installed gitea than a redirect
• Otherwise this appears to be specific to windows machines. Your initial redirect indicates that if there is some URL cleaning being performed then it's being done at the path level on Linux but at the URL level on Windows. (It doesn't make sense to redirect back to the same URL path - which is what it looks like it's trying to do!)

I guess we just need to look at the redirects in the code and check em

[0x5c]

Okay, I was finally able to reproduce it in linux, using curl -I --path-as-is.
However, it does not reproduce when testing against a latest host, like try.gitea.io.

[misterpoesy]

I test again, after installation and creating an admin user. the problem still not solved.

Maybe the only solution is migrating to linux. - -b, with 50GB repositories 😭

[0x5c]

My linux install displays the same behaviour
But try.gitea.io, which runs on the latest commit, is not

[zeripath]

We just need to find out which redirect is causing the problem. Do the v1.7 RCs have the redirect issue you've found? I'd check myself but I'm not at a dev box today.

[zeripath]

OK, I've found where the redirect is being sent.