I have made a upload page to upload dll to server, many of the times the dll gets corrupt on upload.
How do I detect that the file uploaded is corrupt or not in asp.net?
There's no way to detect a corruption without something else as a reference (eg, MD5 sum). Any file can contain any data, so simply inspecting a file without any semantics at all won't tell you anything.
Is it only dll files that get corrupted? Not sure why this would be the case, but zipping them might help? You would need to create some kind of late binding test method or something to test the dll.
Related
I saw this question:
ASP.NET File Upload: how can I make sure that an uploaded file is really a JPEG?
and similar questions about being sure of the file being uploaded through asp:FileUpload control in ASP.net is really image. But What If users upload virus-infected images? How can I be insured of the image files being uploaded via my ASP.net application does not affect the files in my web app folder and/or images uploaded by other users?
As long as you don't serve it back to anyone as anything other than an image (content-type) and never trying to execute (.exe) the file you'll be fine.
Most anti-virus software run whats known as an "on-access scan". That is, when a file is changed, it automatically scans that file.
So save that file to the file system and let your server's anti-virus software do the work for you.
I'll take what is likely a somewhat controversial position.
There is no way to know with 100% certainty what the intent of a file is, be it good or evil. It is impossible. AV scanners give you a slice of data but they can't give you 100% guarantees either. No one can.
Given this reality, you need to build your app assuming that all files uploaded are bad. Yes, scanning is still fine and will filter out a bunch of stuff. But it will never be 100%. Is it 99.999% or 20%? Who knows. Does it really matter?
I would build any app today assuming that all user supplied content is bad. Very bad. Hostile bad. Because eventually it will be if you make it. And when it is, you'll be ready for them...rather than all the people that have to rearchitect their app because they made bad assumptions early on.
With a bit more data about your exact concerns, I'd be happy to comment on them more specifically...
As a side note, In older version of IIS (6 or prior versions) It could be possible to change FileName to the real malicious file name after save the file with original filename. Which has possibility to be read and execute regularly by the server.
E.G. set the file name like: file.asp;.jpg or file.asp%00.jpg etc...
It also has a possibility to change target directory by manipulation of file name. Which is extremely dangerous
E.G. newfolder.asp::$Index_Allocation or etc...
There is also some new way of attacks. Read more here.
Is it possible to know the Exact Path of the File on the Server. For example this URL http://www.hdfcsec.com/Research/ResearchDetails.aspx?report_id=2987918 resolves to a PDF. How to determine the direct location to the PDF file ? Any tools like network connection traces or pointers to find the same is appreciated.
Thanks.
Short of examining the actual source of ResearchDetails.aspx and figuring out where it takes its file from, no. Server-side scripts (and non-script binaries) can handle the request in any way they need and produce any data. There are cases where PDFs are dynamically generated by scripts and do not exist as actual files at all.
I am looking for a good solution by which we can prevent an exe file to be uploaded on server.
It will be best if we can discard the upload by just reading the file headers as soon as we receive them rather than waiting for entire file to upload.
I have already implemented the extension check, looking for a better solution.
There is a how and a when/where part. The how is fairly simple, as binary files do contain a header and the header is fairly easy to strip out and check. For windows files, you can check the article Executable-File Header Format. Similar formats are used for other binary types, so you can determine types you allow and those you do not.
NOTE: Linked article is for full querying of the file. There are cheap, down and dirty, shortcuts where you only examine a few bytes.
The when/where depends on how you are getting the files. If you are using a highly abstracted methodology (upload library), which is fairly normal, you may have to stream the entire file before you can start querying the bits. Whether it is streamed into memory or you have to save and delete depends on your coding and possibly even the library. If you control the streaming up, you have the ability to stream in the first bytes (header portion) and abort the process in mid stream.
The first point of access to uploaded data would be in a HttpModule.
Technically you can check before all the bytes are sent if you have an .exe on your hands and cancel the upload. It can get quite complicated depending on how far you want to take this.
I suggest you look at the HttpModule of Brettle's NeatUpload. Maybe it gives you a lead on how to deal with this on the level you want.
I think you can do that by a javascript by checking if the file end with .exe before submitting the data and also do the check server side.
I'm working on an asp.net /c# app
I need my app to allow users to upload .XLS files (located on the user machine).
How can i read data from the .XLS file but without saving the file on server?
tks
In order to be able to do something with the file on the server (eg using ASP.net ) you will have to at least temporarily save the file on the server. Although an apache module might let you interupt the stream as it is uploaded, but thats probably a bit ott.
There MAY be something you could do in Javascript but I doubt it.
An idea would be to parse .csv files, if it possible. I can send example.
Also you can parse .XLS files through interop excel dll. But it very slow method.
I have a .ddb file that is used as a telephone directory for an application written in flash/VB.net (i guess). The problem is that the application is crashing and my only was to access the application is through the mysterious (*.ddb) file (99% of the application size.)
The application contains an also mysterious dll (NK_SQLite.dll).
So far I have tried:
SQLite Browser
tried opening the file in PL/SQL
tried opening the file in SQL Server
Any ideas about how to solve this issue,
Is it possible that the DDB extension is misleading? Have you tried opening it as a CAB or ZIP file? The NK_SQLLite.dll file certainly makes it sound like a SQLLite database but again it could be a red herring.
Another possibility... if any of the code is .NET, have you tried disassembling it? You might get some hints about what's going on that way, so long as it's not obfuscated. If you're unfamiliar with how to do that, I would recommend a tool like RedGate's Reflector (http://www.red-gate.com/products/reflector)