Project

General

Profile

Actions

Bug #1909

closed

Internal path with multiple dots causes http 400 error (bad request)

Added by Anonymous almost 11 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
Start date:
05/20/2013
Due date:
% Done:

0%

Estimated time:

Description

I'm building media gallery that uses internal path similar way as WMenu and WMenuItem.

When item's componentPath (which is also file name) contains multiple dots next to each other, image is not loaded and Wt responses with http error 400 bad request:

127.0.0.1 - - [2013-May-20 00:43:33.816131] "GET /gallery_name/Image_with_3_dots....jpg HTTP/1.1" 400 89

If those 3 dots are removed (the last one is kept for extension) it works without error.

I cannot remove those dots because another logic depends on it...


Files

fix_using_boost.patch (762 Bytes) fix_using_boost.patch uses boost to simplify code Anonymous, 05/22/2013 09:21 PM
fix_using_std_string_only.patch (671 Bytes) fix_using_std_string_only.patch stays with std:string Anonymous, 05/22/2013 09:21 PM
fix_using_std_string_only.patch (833 Bytes) fix_using_std_string_only.patch Anonymous, 05/25/2013 10:47 PM
Actions #1

Updated by Anonymous almost 11 years ago

Test case:

WMenu *menu = new WMenu(new WStackedWidget(), root());
menu->setInternalPathEnabled("/");
WImage *testImage = new WImage("/images/test....jpg"); // <<< see note 1
WMenuItem *menuItem = new WMenuItem("test", testImage);
menuItem->setPathComponent("test....jpg"); // <<< see note 2
menu->addItem(menuItem);
  • note 1: image with dots in file name is never displayed in browser.
  • note 2: (for files without multiple dots) internal path with dots is shown correctly in address bar when clicked to menu item, image is shown as well, but when I hit F5 to load a page directly from path http://localhost:8080/test....jpg I see just "400 Bad Request" error page.

There has to be some unwanted restriction in Wt which should be removed.

Actions #2

Updated by Wim Dumon almost 11 years ago

Wt's implementation to avoid access outside of httpd's docroot is simple and on the safe side: it disallows any two dots anywhere in the url path. Side effect is that the built-in httpd cannot serve files with multiple consecutive dots.

See src/http/RequestHandler.C, and search for "..".

Wim.

Actions #3

Updated by Anonymous almost 11 years ago

Well, that sounds reasonable.

But current implementation is a bit weak.

What about replacing one current condition by two others and searching whether path:

  • doesn't contain "/../" or
  • does not end with "/.."?

IMHO that allows any combinantion of dots in file name and still stays on safe side...

Actions #4

Updated by Wim Dumon almost 11 years ago

... on unix. But what about Windows?

This is quite system-dependent and crucial for security reasons, so if we modify it we must be 100% sure about the fix.

Wim.

Updated by Anonymous almost 11 years ago

Guessing from currently used condition (... req.request_path[0] != '/' ...) and assumption that response path is usual URL, the only path separator is '/' which is same on all platforms. Am I wrong?

Take a look at following two patches, it's just a proposal, I didn't try to compile ;-)

Actions #6

Updated by Wim Dumon almost 11 years ago

While \ is not used in a URL as path separator, you can still type it, and when passed to windows' file routines, it will certainly be interpreted as a path separator. And while some browsers (IE, Chrome) translate \ in /, others (firefox) don't, and don't forget that you can still URL-encode the character, or write your own non-compliant browser.

Your patches are a security problem on windows.

BR,

Wim.

Actions #7

Updated by Anonymous almost 11 years ago

All URL-encoded characters are already decoded few lines before these modifications so the only missing is handling of backslash.

Please check new version of patch.

Now the code should be directory traversal safe.

Actions #8

Updated by Koen Deforche almost 11 years ago

  • Status changed from New to Feedback

Hey,

I would prefer the following change: we only demand that the URL does not contain '..' characters for static replies, but leave '..' characters in the URL for requests that are forwarded to a Wt application. In this way it's up to the developer's responsibility to sanitize the path if they wish to interpret it as a file.

That would work for you as well?

Regards,

koen

Actions #9

Updated by Anonymous almost 11 years ago

Yes, that could help, thanks.

Actions #10

Updated by Koen Deforche almost 11 years ago

  • Status changed from Feedback to Resolved

Hey,

I've implemented this in my git copy now.

Regards,

koen

Actions #11

Updated by Koen Deforche over 10 years ago

  • Status changed from Resolved to Closed
  • Target version set to 3.3.1
Actions

Also available in: Atom PDF