Какие проблемы безопасности появляются, когда пользователи могут загрузить свои собственные файлы?
Вы можете попробовать удалить все из локального хранилища перед записью обновленного объекта:
localStorage.clear();
Кроме того, проверьте, как он будет работать с sessionStorage.
4 ответа
Your first line of defense will be to limit the size of uploaded files, and kill any transfer that is larger than that amount.
File extension validation is probably a good second line of defense. Type validation can be done later... as long as you aren't relying on the (user-supplied) mime-type for said validation.
Why file extension validation? Because that's what most web servers use to identify which files are executable. If your executables aren't locked down to a specific directory (and most likely, they aren't), files with certain extensions will execute anywhere under the site's document root.
File extension checking is best done with a whitelist of the file types you want to accept.
Once you validate the file extension, you can then check to verify that said file is the type its extension claims, either by checking for magic bytes or using the unix file command.
I'm sure there are other concerns that I missed, but hopefully this helps.
size validation would be useful too, wouldn't want someone to intentionally upload a 100gb fake image just out of spite now would you :)
Also, you may want to consider something to prevent people from using your bandwidth just for a easy way to host images (I would mostly be concerned with hosting of illegal stuff). Most people would use imageshack for temp image hosting anyway.
С более широким контекстом было бы легче узнать, где могут лежать уязвимости.
Если данные могут быть сохранены в базе данных (звучит так, как будто это не так), то вы следует защищать от атак SQL Injection .
Если данные могут отображаться в браузере (похоже, что это так), вам может потребоваться защита от HTML / CSS Injection Атаки.
Если вы используете скриптовые языки (например, PHP) на сервере, то вам может потребоваться защита от инъекционных атак на эти специфические языки. Скомпилированный серверный код (или плохая реализация сценариев) может привести к атакам с переполнением буфера.
Не забывайте также и о безопасности пользовательских данных: могут ли ваши пользователи доверять вам, чтобы предотвратить компрометацию их данных?
РЕДАКТИРОВАТЬ : Если вы действительно хотите охватить все базы, учтите риски дыр в безопасности JPEG и WMF . Они могут быть использованы, если злонамеренный пользователь может загрузить файлы из одной системы, а затем просмотреть файлы - или убедить другого пользователя просмотреть файлы - из другой системы.
Assuming you're dealing with only images, one thing you can do is use an image library to generate thumbnails/consistent image sizes, and throw the original away when you're done. Then you effectively have a single point of vulnerability: your image library. Assuming you keep it up-to-date, you should be fine.
Users won't be able to upload zip files or really any non-image file, because the image library will barf if it tries to resize non-image data, and you can just catch the exception. You'll probably want to do a preliminary check on the filename extension though. No point sending a file through the image library if the filename is "foo.zip".
As for permissions, well... don't set the execute bit. But realistically, permissions won't help protect you much against malicious user input.
If your programming environment allows it, you're going to want to run some of these checks while the upload is in progress. A malicious HTTP client can potentially send a file with an infinite size. IE, it just never stops transmitting random bytes, resulting in a denial of service attack. Or maybe they just upload a gig of video as their profile picture. Most image file formats have a header at the beginning as well. If a client begins to send a file that doesn't match any known image header, you can abort the transfer. But that's starting to move into the realm of overkill. Unless you're Facebook, that kind of thing is probably unnecessary.
Edit
If you allow users to upload scripts and executables, you should make sure that anything uploaded via that form is never served back as anything other than application/octet-stream. Don't try to mix the Content-Type when you're dealing with potentially dangerous uploads. If you're going to tell users they have to worry about their own security (that's effectively what you do when you accept scripts or executables), then everything should be served as application/octet-stream so that the browser doesn't attempt to render it. You should also probably set the Content-Disposition header. It's probably also wise to involve a virus scanner in the pipeline if you want to deal with executables. ClamAV is scriptable and open source, for example.