[SOLVED] directory traversal security issue

Answered Closed
0
0

While playing with your beautiful framework I found a critical security issue which allows to do a directory traversal attack. It is possible to download and delete files on the server.

For example, to download the web.config you can call
http://demo.wisej.com/desktop/resource.wx/web.config
or
http://demo.wisej.com/desktop/download.wx?x=eyJmaWxlIjoid2ViLmNvbmZpZyIsIm5hbWUiOiJ3ZWIuY29uZmlnIiwiZGVsZXRlIjpmYWxzZX0=

Using the download.wx an attacker needs to know that the x-parameter is a base64 encoded string. The decoded example above is {“file”:”web.config”,”name”:”web.config”,”delete”:false}
To delete an file an attacker needs to change the delete property to true.

Maybe the resource.wx should only allows files from specific whitelisted folder. The download.wx should use a token generated per session by Application.Download to avoid an information disclosure.

best regards

Bernhard

  • You must to post comments
Best Answer
0
0

Thank you again. There was something that didn’t feel right about those callbacks…

This is how we solved it:

  • all internal resource requests must include a valid/active session id in the base64 package: when the session is retrieved by Wisej SessionManager it always checks the client fingerprint to avoid session hijacking.
  • all download requests (without the session id – since we don’t want to give out the sid in a downloadable link) are limited to the application’s root folder or the application’s temp folder in {system’s temp}\Wisej\{ApplicationName}\Temp.
  • the delete option is removed and temporary images are deleted by default.
  • all downloads from /bin are disallowed.
  • all download from /App_Data are disallowed.
  • all .json, .config, .dll downloads are disallowed.
  • for resources requests, only these types are allowed: jpg, gif, jpeg, png, js, css.

Please note that these restrictions only apply to files and resources managed by Wisej. Any common file/image request will always go through the browser.

When any of the conditions above fails, wisej returns 404 (not found).

We will keep checking for any additional potential unsafe resource access.

/Luca

 

  • You must to post comments
0
0

Hi
Some way to allow other types inside wisej extension? Or another approach/advice?
I trying to make a extension that uses url inside embeded css like:
…/resource.wx/Wisej.Web.Ext.Foo/WiseJ.Web.Ext.Foo.FontAwesome.otf

But some resources doesnt work, like embeded resource fonts or others embeded files like PDF
pdf, eot, otf, ttf, woff, woff2 etc…

Thanks in advance!

  • Luca (ITG)
    To return embedded resources you can use the IWisejHandler interface on any component and return anything in ProcessRequest. You can load them from the assembly, or files, or load a new assembly, or load them from the database, etc. The only problem would be how to put them in a css since you the css is static and you don’t have the session there. Which is exactly the security risk since resource.wx does’t care about the session and the url works at all times. We can add a configuration setting in Default.json to let you modify the list of allowed extensions. I’m not sure about that though. It would be safer to be able to specify individual files, otherwise you may open all pdfs to anyone with a link.
  • You must to post comments
0
0

Bernhard,

this has been logged as WJ-7254 and already fixed in the nightly build (1.1.90.0), the way Luca described it.

Best regards
Frank

  • You must to post comments
0
0

Hi Bernhard,

thanks for bringing this our attention. I have logged this security as WJ-7254 and we will adress it asap.
I will post an answer when it is fixed.

Best regards
Frank Boettcher

  • You must to post comments
Showing 4 results