Wt

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.

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.

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...

... 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.

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.

Yes, that could help, thanks.