Я создаю сайт, на котором используется Perl-скрипт, PHP, база данных MySQL и HTML. Моя главная забота заключается в том, чтобы убедиться, что в любом случае кто-то может получить доступ ко всему, что дает им доступ к моей информации. Я имею в виду, так или иначе, чтобы кто-то получил мой скрипт perl и посмотрел мою базу данных. Я знаю о sql-инъекции, но у меня нет форм для ввода информации. Есть ли что-нибудь, что я должен помнить об этом.
все равно кому-то получить мой скрипт perl и посмотреть мою базу данных
Это произойдет только тогда, когда веб-сервер не будет анализировать / обрабатывать сценарий и не возвращает его в качестве открытого текста. Обычно этот синтаксический анализ / обработка происходит только в определенных расширениях файлов, таких как .pl для perl-файлов и .php для файлов PHP. Если вы (или хакер) переименовываете его в .txt , клиент сможет получить весь скрипт как открытый текст. Тем не менее, если хакер может переименовать его, он все равно имеет доступ ко всему скрипту. Тогда это будет сделано дырой безопасности в FTP или CMS.
Кроме того, я видел сценарии, которые читают файлы (обычно изображения или другие статические файлы) из (вне) контекста webapp на основе пути в качестве параметра. Например, download.php?filename.ext Если такой скрипт не выполняет никаких проверок на пути к файлу, смарт-хакер может получить скрипты в виде открытого текста download.php?%2Fserver%2Fhtdocs%2Fscript.php .
Широта этого вопроса довольно подавляющая, но это большой вопрос и определенно важный.
Большая часть проблем, которые вы будете иметь с вашим сервером, может быть привязана к самому доступу к серверу, убедитесь, что вы не используете какое-либо программное обеспечение, которое вам не нужно. Если вам не нужен сервер имен, отключите bind; То же самое касается ftp, даже sendmail, если можно. Используйте сильные пароли и альтернативные порты, если это возможно.
Для PHP см. http://us3.php.net/manual/en/security.php и http://php-ids.org/ ; определенно используйте mysql_real_escape_string () и htmlentities ().
Для HTML / PHP / JS см. http://en.wikipedia.org/wiki/Cross-site_scripting
О многом нужно подумать. Я бы рекомендовал найти наставника, чтобы помочь вам понять, что важно. Я наставляю парня прямо сейчас, и он очень помогает ему, даже если я не совершенен. SO может помочь, но человек, которому вы доверяете, который может посмотреть, как вы это делаете, может давать рекомендации, которые вы просто не получите здесь, если не будете размещать всю свою базу кода.
Используйте заполнители для SQL, даже PHP поддерживает его.
Побег вашего выхода. Ваша система шаблонов может помочь здесь.
Используйте каталог cgi-bin. Это действительно помогает защитить случайные утечки. Легко создавать URL-адреса без cgi-bin.
В Perl используют taint mode, в PHP используют упрочненный PHP.
Безопасность веб-приложений – большая тема. Однако вы знаете об одной из самых больших уязвимостей там, SQL Injection, так что это хороший старт.
Пара других крупных – это скрипт Cross Site (XSS) и кросс-сайт (CSRF – «See-Surf»)
XSS – http://en.wikipedia.org/wiki/Cross-site_scripting
CSRF – http://en.wikipedia.org/wiki/Csrf
Как обычно, Википедия дает хорошее введение.
Вы также можете захотеть проверить достоверность запроса с помощью HMAC
http://en.wikipedia.org/wiki/HMAC
Действительно прочитайте эту вики сообщества . Его полная информация. Или просто искать здесь в stackoverflow есть много вопросов.
Никогда не доверяйте ни одному пользователю в любой форме.
Жесткая часть – это поиск всех способов, которыми пользователь может предоставить вход на ваш сайт.