skip to Main Content

I’m not an expert in cyber security and exploits. I need help figuring out if my app is vulnerable and in what way.

Let’s assume I’m an idiot (and I’m not to this extent), and I leave the possibility for client users to upload (exploiting my front end) any file they want on my server in a subfolder (let’s call it ‘danger’) of my ASP.NET application, hosted on IIS.
Being that way, anybody can upload a generic example.hml file and access it back at the url mydomain.com/danger/example.html. They can also upload JS files and whatever they want.

Let’s forget for a moment the fact they can fill my disk.

Given I prevented ASP execution from files in that folder, what kind of damage can I be subjected to?

Thanks in advance.

2

Answers


  1. Well, yes, you do have to be carefull IF YOU allow any kind of preview, or say allow the person to download the file, but when you download, you also attempt some kind of preview on the server.

    In fact, this is not a lot different then dropping a simple text box into a form, and then letting the user type in information into that text box, you then say hit submit button, and now re-display the page with what they just typed in.

    What happens if they start typing in javascript text into that text box?

    Say a multi-line text box in which you can type in a paragrath of comments or text.

    So, you type in this:

    Hellow how are you
    <script>
         JavaScript code here
    </script>
    

    Now, when you go to re-plot the page – not only are you re-display of what was typed in, but those script code typed in ALSO will run!

    In fact, if you drop a text box on a web page, and do this:

     Hello, how <script> are you
    

    You notice you get a page exectution error. (becuase asp.net has built in protection to NOT allow this). However, if you adopt some html editor text box (ckEdit, or ajaxtoolkit editior), such controls will have additional security code to prevent end users from typing in script code.

    So, a few things you have to be concered about:

    If you allow up-loading of files, then ensure that you don’t have code that attempts to load/execute that file. So, you might allow users to up-load pdf files, and then maybe a routine that attempt to "open" or use that file. But what happens if they in place of a pdf file up-load a MyTest.exe. In other words, they up-load a exectuable program in place of a pdf? Well, then you mostly ok, but you BETTER NOT have code that attempts to load such files – especially code behind that may use some library or code that in effect launches that pdf or word or exec file. Since that code then might try to load or run what is now a .exe program.

    So, this means a few things:

    You want to limit the file extensions allowed
    You need to ensure that your code does not "execute" that up-load file
    If you allow download of that file, then careful how you do this
    (again, ensure that you don't open up possibiity to execute that file).
    

    So, for the most part you should be ok, but if up-loaded files are further processed by your server side code, then just be aware of HOW you open or process such up-loaded files.

    As noted, say users up-load a simple text file, and after up-loading you take the text from that file, and then display it in some kind of memo or text box in a web page. But, again, you sure it is just text in that file? And if you pull the content from that file and THEN have it render in your browser (because you assumed text), but it now might have browser code injected into that text file.

    So, any point in your server side code that opens up-loaded files, pulls the content and THEN say spits out that content for display of data is a caution area.

    So, the first simple line of defense?

    Limit the types of files. If users are expected to upload only PDF files then ONLY allow say PDF and maybe .zip file extensions – reject anything else.

    And as noted, just keep in mind any kind of post-processing code you have that runs AFTER up-loading that file. If your site is taking such up-loaded files, and is to open up the file(s), AND THEN DISPLAY that content back to the end user, then again caution is required, since when you display such content in a browser, that content in theory can have script code – and like anything else your code spits out to the browser (like a web page with HTML etc.) also means that the browser will run that script code.

    I mean, a browser simple takes whatever the server sends to that browser, and renders the HTML. However, these days, browsers have MUCH more ability to also run code in that browser. So, that’s why now you can say run cool games 100% in a browser, since browsers have become VERY powerful systems, and almost their own computer system in their own right. So, the ability of browsers to run code and give an experience that rivals the desktop in terms of speed and response (and even interactive games) is the result of browsers now being able to run code and do much MORE then just display some simple HTML.

    So, under no case should you allow up-loading of files, and then have some software that can "run" or even pull contents of that file and spit it out back to the user in the form of browser display. And the reason is that file content may well have executable code in that file contents.

    Login or Signup to reply.
  2. Just off the top of my head:

    An attacker could upload a corrupted file which would trigger a remote-code execution vulnerability in your antivirus, potentially executing code under the local system account. (I’ve seen this happen with Windows Defender, and I’ve seen reports of similar vulnerabilities in other AV products.)

    They could upload a file with a mangled name which exploited a bug in IIS to bypass your file-type checks and the "no execute" flag on the folder. (I’ve seen this reported, albeit in a very old version of IIS.)

    If the files can be accessed publicly, they could host their own content on your site, potentially including illegal or malicious content. This could damage your site’s reputation, and potentially leave you liable to prosecution.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search