- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть проект типа конструктора сайтов, где все пользователи работают из-под одного юзера (php установлен как модуль апача). По многочисленным просьбам клиентов пришлось сделать файловый менеджер, теперь каждый клиент может заливать файлы в свою папку. Но посколько все пользователи фактически работают под одним юзером апача есть вопросы по безопасности. Я сделала так, что возможна заливка файлов определенных расширений (gif, jpg, png, rar, zip, tar, doc, rtf и т.д.).
Вопрос: безопасно ли это? Может ли кто-то из клиентов как-то извратиться, залить нехороший файл и запустить вредоносный код? Где можно почитать о безопасности заливки файлов на сервер?
gif, jpg, png, doc, rtf - вполне безопасна
.zip .rar - могут содержать (самораспаковывающиеся архивы) всё что угодно, начиная от шелла (скрипт узнает ваши пароли) до троянов.
Решение - запретить добавлять архивы, добавив нужные разрешения - .djvu, .avi, .flv и т.д.
Я сделала так, что возможна заливка файлов определенных расширений (gif, jpg, png, rar, zip, tar, doc, rtf и т.д.).
Вопрос: безопасно ли это? Может ли кто-то из клиентов как-то извратиться, залить нехороший файл и запустить вредоносный код?
Безопасно, если речь идет только о запуске этого нехорошего кода на стороне Вашего сервера.
Где можно почитать о безопасности заливки файлов на сервер?
Так сразу не скажу, гугл знает.
В любом случае не мешает освежить память:
http://ru.php.net/manual/en/function.move-uploaded-file.php
http://php.about.com/od/advancedphp/qt/upload_security.htm
http://httpd.apache.org/docs/2.2/mod/mod_mime.html#addtype
содержание настроек .htaccess (или других настроек http-сервера) действующего на директории куда грузится?
содержание настроек .htaccess (или других настроек http-сервера) действующего на директории куда грузится?
Файл .htaccess закачивается в корень папки, начиная с которой эти настройки должны действовать.
В большинстве случаев это корень сайта для общих настроек на сайт и определенные папки, куда доступ нужно закрыть или изменить поведения некоторых файлов (например, отдавать php-скрипт как файл, а не выполнять его на стороне сервера).
Решение - запретить добавлять архивы, добавив нужные разрешения - .djvu, .avi, .flv и т.д.
Это не взаимозаменяемые файлы. В моем случае заливка файлов делается для возможности клиентов торговать в магазине виртуальными товарами. А это не всегда фильмы или электронные книги, чаще всего шароварщики своими программами торгуют, поэтому без архивов не обойтись.
содержание настроек .htaccess (или других настроек http-сервера) действующего на директории куда грузится?
.htaccess лежит в папке на уровень выше от папок для загрузки файлов каждого клиента.
Где лежит .htaccess имеет значение? Этим могут как-то воспользоваться или его переопределить? Создание и редактирование файлов без расширения я запретила, подниматься на уровень выше директории для заливки файлов тоже вроде запретила. Правда по тупому – только невозможностью .. в пути.
Самое безопасное это хранить файлы в недоступном для юзеров месте.
1) База данных:) Отдача скриптом и нагрузка.
2) Папка выше www. Отдача скриптом и нагрузка чуть меньше чем в 1-ом варианте.
3) Просто отдача скриптом, папка закрыта от юзеров.
4) Отдача файлов напрямую, но запрещено выполнение скриптов в папке где они хранятся.
Первый вариант самый безопасный с точки зрения серверной безопасности и универсальный и простой, можно просто хранить все так, как оно пришло, без фильтраций и еще чего-бы то ни было.
Вы правильно делаете что фильтруете по расширению файла (некоторые почему-то считают что достаточно проверять приходящий mime тип, хотя это просто данные приходящие от пользователя, а не "подлинный" mime тип - из-за этого кстати в доброй половине виденных нам скриптов аплоада есть дыра).
Но не забывайте, что в фильтрации по расширению есть небольшой "нюанс" (подробнее тут http://httpd.apache.org/docs/1.3/mod/mod_mime.html ). Например файл http://zc.tj/temp/a.php.mmf - выполнится как пхп скрипт, хотя некоторые скрипты восприняли бы его как файл с разрешением mmf.
По поводу "запрещения подниматься выше - запретом в пути", через realpath? Тогда в принципе правильно. Только еще есть определённый смысл ограничить права для вышестоящих папок, что бы скрипты в принципе туда ничего не могли загружать. И конечно нужно отключить выполнение скриптов - так же в .htaccess, т.к. "пути файлов неисповедимы" и лучше перестраховаться от попадания скрипта в папку, чем верить что он туда не попадет.
И конечно все имена файлов лучше не брать "от юзера", а тупо переименовывать их в a-z0-9_- буковки. Тоже на всякий случай.
Самое безопасное это хранить файлы в недоступном для юзеров месте.
1) База данных:) Отдача скриптом и нагрузка.
2) Папка выше www. Отдача скриптом и нагрузка чуть меньше чем в 1-ом варианте.
3) Просто отдача скриптом, папка закрыта от юзеров.
4) Отдача файлов напрямую, но запрещено выполнение скриптов в папке где они хранятся.
Лучше всего отдавать файлы не напрямую и не скриптом, а nginx-ом, если он установлен. Это быстрее, чем просто отдача скриптом и надежнее чем отдача напрямую. Подробнее об это способе можно прочитать здесь.
edogs, спасибо, много нового почерпнула