I'm doing a project on SQLNinja for school and in common types of attacks they discuss uploading binary files as seen here in the upload section: http://sqlninja.sourceforge.net/sqlninja-howto.html#ss2.6
I assume this is to gain access to the database or modify it but I would basically like to know how? What would be uploaded to allow a user to proceed with an attack? Or why else would someone upload a file to a server in this way?
One of the biggest cases of identity theft occurred in 2007, when a hacker uploaded a binary to ATM machines, which recorded credit card and debit card numbers. He accomplished the upload using SQL injection.
Read "The Great Cyberheist" (New York Times)
https://www.nytimes.com/2010/11/14/magazine/14Hacker-t.html
https://www.owasp.org/index.php/Unrestricted_File_Upload
File upload can allow for attacks from filling up the disk space, to potentially making it easier to execute the binary later through other flaws in the system.
Related
In the documentation sample code for how to deal with user uploaded files, they save it as a trusted filename for filestorage via GetRandomFileName, and a trusted filename for HTML display.
In the comments it says: "In most production scenarios, an anti-virus/anti-malware scanner API is used on the file before making the file available for download or for use by other systems."
Is that going to be before it is saved with a random filename or after? Because that is the point of saving it as a random filename, so that it doesn't get executed? And when the scanning is done, how is the file going to be made available? I guess the file just has to be renamed if it passes the scan or else deleted? If so, what is the proper way to get the original file extenstion? And do you know of any good scanners that are gratis that are popular to use?
I try to learn web development. Thanks for your time and help.
The renaming of the file here has nothing to do with the anti-virus protection. The files don't tend to execute themselves whatever their name is. Same with the virus scan: it's not for the server protection, it's for the users protection. If your server executes the binary it gets from the client, it's a security breach regardless of whether it's a virus or not.
The renaming here is probably done just to be able to store the duplicates. That being said, in the production scenarios you'll probably never store the incoming files as physical files on the FS. They usually go to the DB as blobs, so the name is not an issue.
This is just a sample app designed to teach how to work with binary streams and file controllers. Don't expect too much from it in terms of applicability to the real solutions.
I need to build a tables related to manage documents such as jpg,doc,msg,pdf using a sql server 2008 .
As i know sql server support .jpg images, so my question is if it's possible to upload other kind of files into a db.
This is an example of the table (could be redefined if it's needed).
Document : document_id int(10)
name varchar(10)
type image (doesnt know how it might works)
Those are the initial values for a table, but i dont know how to make it useful for any type.
pd: do i need to assign a directory to save this documents into the server?
You can store almost any file type in an sql server table...if you do, you will almost certainly regret it.
Store a meta-data / a pointer to the file in your database instead, and store the files themselves on a disk directly where they belong.
Your database size - and thus hardware required to run it - will grow very rapidly, so you will be incurring large costs that you do not need to incur.
Use Filestream
https://learn.microsoft.com/en-us/sql/relational-databases/blob/filestream-sql-server
I know that a link-only answer is not an answer but I can't believe no one has mentioned it yet
The proper database design pattern is not to save Files into DBMS. You should develop a kind of File Manager Subsystem to manage your files for all of your projects.
File Manager Subsystem
This subsystem should be Reusable, Extendable, Secure and etc. All your projects that want to save Files, can use this subsystem.
Files can be saved in every where such as Local Hard, Network Drive, External Drives, Clouds and etc. So this subsystem should be design to support all kind of requests.
(you can improve the mentioned subsystem by adding a lot of features to it. for example checking duplicate files,...)
This subsystem, should generate a Unique Key for each file. After uploading and saving the files, the subsystem should generate that key.
Now, you can use this Unique Key to save in database (instead of file). Every time if you want to get the file, you can get the Unique Key from database and request to get file from the subsystem by unique key.
We've been on SharePoint 2007 for close to 2 years now. We find it's a great CMS that helps us centralize project documents and colaborate with less duplication and confusion. The custom list feature offers a quick and dirty alternative to custom form and developed sql solutions sometimes.
That said, we still have over 100 Terrabytes of files shares with documents dating far back to the beginning of time outside of SharePoint.
As we look forward to smarter, faster and bigger Network FileSystems...
(1)What realistic role should SharePoint play?
(2) How reliable can SharePoint be as a seemless place to store documents? I mean, will we be able to save/retrieve documents to sharepoint from all popular clients without having to open sharepoint?
Part of why I ask ... A few months ago as part of another project, we attempted to use SharePoint 2007 like a file share.. attempting to set up a Windows drive map and UNC path and/or WebDAV. Our findings were that not every client (XP, Vista, 7, Mac. IX, etc) plays nice with UNC, WEBDAV and drive mappings. Not surprised. Does this change significantly looking ahead to future sharepoint releases?
(3) Are there documents that have no business in SharePoint? Databases? Executables? propietary logs? What about documents where we expect lots for row level IO from potentially multiple users?
(4) How many customers would you say are seriously looking at SharePoint as a significant alternative to file shares? I understand SharePoint DBs should not exceed 100g - so we have a DB for every site collection. But we have over 100T of potential content. If there are customers seriously looking to go this way - what might there archetecture look like? Blob storage outside of SQL? EBS vs RBS? Who are the major players that offer this and will SharePoint ever offer this natively? EMC? StoragePoint? who else? EBS vs RBS?
(5) What about performance and content indexing concerns?
Thanks in Advance.
If you're seriously consider BLOB storage and SharePoint, then your should look into Remote Blob Storage. See Overview of Remote BLOB Storage. Besides the free FILESTRAM based provider, there are 3rd party providers of RBS that can place the BLOB on SANs like the EMC one.
Metalogix's StoragePoint has an offering called FileShare Librarian that may be the answer you are looking for, it will quickly create the file structure and permissions in SharePoint, while leaving the BLOB's externalized. There is all FileShare Migration Manager for a full fidelity migration, you can still externalize the blobs to EMC with StoragePoint.
I recently came across a problem for image file storage in network.
I have developed a desktop application. It runs in network. It has central database system. Users log in from their own computer in the network and do their job.
Till now the database actions are going fine no problem. Users shares data from same database server.
Now i am being asked to save the user[operator]'s photo too. I am getting confused whether to save it in database as other data or to store in separate file server.
I would like to know which one is better storing images in database or in file server?
EDIT:
The main purpose is to store the account holder's photo and signature and later show it during transaction so that teller can verify the person and signature is correct or not?
See these:
Storing images in database: Yea or nay?
Should I store my images in the database or folders?
Would you store binary data in database or folders?
Store pictures as files or or the database for a web app?
Storing a small number of images: blob or fs?
User Images: Database or filesystem storage?
Since this is a desktop application it's a bit different.
It's really how much data are we talking about here. If you've only got 100 or so users, and it's only profile pictures, I would store it in the DB for a few practical reasons:
No need to manage or worry about a separate file store
You don't need to give shared folder access to each user
No permissions issues
No chance of people messing up your image store
It will be included in your standard DB backup
It will be nicely linked to your data (no absolute vs. relative path issues)
Of course, if you're going to be storing tons of images for thousands of users, I would go with the file system storage.
I think you have to define what you mean with better.
If it is faster my guess you don't want to use a database. You probably just want it plain on a file server.
If you want something like a mini-facebook, where you need a much more dynamic environment, perhaps you are better of storing it a database.
This is more a question than an answer, what do you want to do with the pictures?
I have a Report Generator which is an intranet web application generates some reports. There are about 100 reports. Those reports are of PDF and Excel type. And I want to ensure that all these reports are generated without any issue. This is a daily job.
Each report takes an average of 2 min. Manual checking process takes 200 min.
As this is a testing process and not bothered about the contents in the files I want to automate the process.
We are using Selenium test cases to test our web application.
Is there any way to Save these reports on my location disk using Selenium ?
To answer your question, no. Browsers won't allow it, unless a user chooses to upload. But even if there is a way, i would advise against using it.
Even if you can do this by any means its HIGHLY NOT RECOMMENDED
This will be a huge security threat and it won't be allowed. Javascript is inside a security sandbox and won't allow these kind of things.
What if the server is sending a potentially dangerous file that might affect the client system?
See JavaScript security
At best, you could display the file download prompt. The browser's security (and common sense :)) won't allow you to do anything more. If you absolutely must do unsupervised file downloads, you could use some kind of ActiveX, or a Java applet.