методы безопасности и проверки веб-приложений на стороне сервера и конечных пользователей

Мне было интересно, какой метод безопасности каждый использует для защиты веб-приложения на банковском уровне, если это возможно.

насколько мне известно, вот методы/технологии, о которых я знаю.

Front - End-user Section
-------------------------
SSL (128 bit encryption)
htaccess (protection against bots and using mod-rewrite to hide parameter calls)
input field cleaning
session cleaning before use
PDO access to mysql ( although oracle is better yet expensive)
not being on a shared hosting account.
using a cisco based firewall (not very familiar with these)
restricting what can be uploaded (if the site requires an upload)
blocking off directory index access with htaccess
not storing credit card information locally
encrypting user passwords with sha1 or encryption with salt 
(never could figure these out)

not using hidden input fields
turn off global variables
turn off error displays
using another file extension displayed to the user rather than php , aspx, etc.
blocking ping/requests for server/apache information and version.


backend access
-------------------
not having its access being something like /admin (if you know what i mean)
"all of the above listed for end-user"
verifying if the user who logs in exists as an admin 

вместо того, чтобы использовать mysql_real_escape_string или htmlentities для очистки полей ввода, есть filter_input(), который не работает так хорошо. это немного портит уборку. так что вы, ребята, порекомендуете. я знаю, что некоторые из вас могут подумать, что это может быть слишком много, но если вы работаете над веб-приложением, которое должно было быть затронуто более чем 50 000 пользователей, где будут происходить транзакции на основе электронной коммерции. Чтобы ты делал?

Благодарность

ps: это то, что у меня есть в htaccess для защиты от недружественных ботов и ограничения доступа к важным файлам.

#=============================================================================#
#          Deny access to hidden files
#=============================================================================#
<FilesMatch "\.(htaccess|log|sh)$">
 Order Allow,Deny
 Deny from all
</FilesMatch>

#=============================================================================#
#          Deny access to evil bots / security
#=============================================================================#

RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^JetCar.* [NC]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^GoZilla.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^ia_archiver.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^wget.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^HTTrack.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCapture.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Scooter-W3.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGe.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Webdupe.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Pockey.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^DiscoPump.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InternetNinja.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:[email protected] [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} ^HTTrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^Indy\ Library [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^RealDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
RewriteCond %{HTTP_USER_AGENT} ^GoZilla.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^WebCapture.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Webdupe.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Pockey.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^DiscoPump.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^InternetSeer.com.* [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://www.hostitcheap.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.bravespider.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.bigweblist.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.weblinkvalidator.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://traffixer.com* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.youradultpaysite.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.paysiteprofits.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.hotlivewebcams.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.paysiteprofits.com/* [OR]
RewriteCond %{REQUEST_URI} FormMail.*
RewriteCond %{HTTP_REFERER} ^www.addresses.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.business-socket.com/* [OR]
RewriteCond %{HTTP_REFERER} ^www.datashaping.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://cheapweb.biz/* [OR]
RewriteCond %{HTTP_REFERER} ^http://traffixer.com* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.hostitcheap.com/* [OR]
RewriteCond %{HTTP_REFERER} ^http://www.weblinkvalidator.com/* [OR]
RewriteCond %{REQUEST_URI} FormMail.*
RewriteRule .* - [F,L]

person george melinda    schedule 21.01.2011    source источник


Ответы (3)


Всего несколько вещей, которые можно добавить к этому приятному большому списку:

  • также удалить информацию о раскрытии версий из PHP (очень подробно): expose_php Off

вместо того, чтобы использовать mysql_real_escape_string или htmlentities для очистки полей ввода, есть filter_input(), который не работает так хорошо. это немного портит уборку. так что вы, ребята, порекомендуете

Ну правило состоит в том, чтобы не отфильтровать один раз и получить с ним. Правило состоит в том, чтобы фильтровать на основе типа вывода в то время, когда вам это нужно.

  • Когда выходом является база данных, escape/фильтр для базы данных (mysql_real_escape и т. д.)
  • Когда вывод HTML escape для HTML (htmlspecialchars)
  • Когда вывод представляет собой escape-последовательность CSV для CSV (разделители, возврат каретки и т. д.)
  • Когда вывод PDF escape для PDF (и т. д., ...)

И вы также должны защитить себя с помощью разных политик для разных типов входных данных. Преобразование целых чисел в целые числа, фильтрация белого списка значений, ограничение длины строки.

  • Отфильтруйте записи (удалите вредные вещи для следующего шага)
  • проверить записи
  • выходные записи (в базе данных или в HTML и т. д.)

В большой системе трудно гарантировать, что это всегда делается, поэтому постарайтесь заранее создать свои собственные объекты, которые гарантируют, что меры безопасности ВСЕГДА выполняются. Не позволяйте какой-либо функциональной части приложения напрямую использовать пользовательские записи ($_GET, $_POST, $_COOKIE, $_SERVER). и не позволяйте им напрямую выводить окончательный вывод (база данных, HTML и т. д.).

Одно действительно полезное чтение на это и на Hugarian Apps: сделать неправильный код неправильным. Второй раз на этой неделе я ссылаюсь на эту страницу, но это действительно потрясающее чтение :-)

Затем для большого приложения я бы рекомендовал (редактировать: Извините, @Cray, я не видел, что вы только что сказали это) с использованием 2 доступа к базе данных, один только для чтения и один для чтения-записи. Используйте доступ для чтения и записи только при необходимости (транзакции и т. д.), вы получите лучшее приложение для масштабируемости и более безопасное всего за одну идею :-).

Изменить: некоторые другие вещи:

  • Сессия дает вам личность, этого недостаточно, вам нужно добавить ACL, контроль доступа. вы должны выполнять проверку списка контроля доступа для каждого запроса, установить его на низком уровне, т.е. попытаться выполнить эту проверку до того, как произойдет кеширование любого приложения. Попробуйте установить политику URL-адресов в своем приложении, которая поможет вам с этой политикой ACL. и не забывайте в нем вызовы AJAX.
  • Базовую безопасность URL-адресов по-прежнему трудно поддерживать, следует ли разрешить пользователю подделывать пользовательские запросы GET и поисковые данные, которые ему на самом деле не было разрешено видеть? Иногда использование скрытых или проверенных токенов GET на стороне сервера в данных сеанса может предотвратить этот ручной поиск.
  • Возможно, вам придется подумать о безопасности на уровне строк в базе данных (например, о виртуальной частной базе данных в Oracle). С современными базами данных, такими как PostgreSQL, вы можете эмулировать его с некоторыми триггерами/правилами и переменными сеанса.
person regilero    schedule 22.01.2011
comment
когда вы сказали, не позволяйте какой-либо функциональной части приложения использовать прямые пользовательские записи. когда я использую ajax, у меня есть параметры публикации, которые отправляют данные, такие как имя пользователя, данные поля и т. д., которые будут использоваться через $_POST , которые затем очищаются, а затем обрабатываются в соответствии с тем, что необходимо. это неправильно/ - person george melinda; 22.01.2011
comment
Что касается того, чтобы ваш код выглядел правильно, вы должны иметь возможность отслеживать использование $_POST и видеть, что он используется только в ваших 2 или 3 функциях фильтра, а не где-либо еще. Конечно, ваш код может быть хорошим и безопасным, но может быть и нет, вы не сможете каждый раз перечитывать все строки банковского приложения, вам нужно соглашение о коде, чтобы помочь вам кодировать безопасным способом. Почему вы должны кодировать свои функции в режиме ajax с помощью разных инструментов, что отличается в режиме ajax? только конечный результат! - person regilero; 22.01.2011

Пройдитесь по каждому сценарию и действительно используйте хорошую санитарию ввода. Если данные должны быть числовыми, убедитесь, что они принимают только числа и так далее. Именно здесь находится большинство ошибок среднего уровня.

В вашем htaccess не должно быть шаблонов для файлов, которые вы хотите заблокировать. Вместо этого заблокируйте все и разрешите использовать только определенный набор файлов, которые, как вы знаете, будут использоваться.

Заставьте приложение (или даже разные части приложения) работать со специально созданными пользователями базы данных с ограниченным доступом. Если часть приложения просто отображает информацию из таблицы, пользователь db, который он использует для подключения к базе данных, должен иметь возможность видеть только эту конкретную таблицу и должен иметь возможность только читать эту базу данных, но не изменять ее. Сообщайте обо всех странных ошибках прав доступа к базе данных в специальный файл и регулярно проверяйте.

Будьте очень осторожны с eval(), очевидно, никогда не запускайте ничего, что приходит из-за пределов скрипта, а еще лучше вообще не используйте eval().

Тщательно установите разрешения для пользователя, с которым работает сервер. Он должен иметь возможность писать только в те каталоги, которые ему нужны, и файлы в этих каталогах никогда не должны выполняться.

И самое главное, никогда не начинайте думать, что ваше приложение безопасно. Нет ничего безопасного. Постоянно появляются новые ошибки и даже типы ошибок, следите за ними. Например, вы можете подписаться на какой-нибудь бюллетень по безопасности и проверить наличие новых ошибок и эксплойтов, а затем попытаться подумать, можно ли использовать такой же эксплойт в какой-то части вашего приложения.

person Cray    schedule 22.01.2011
comment
спасибо за это представление. относительно прав доступа к БД. Должен ли я установить другой логин пользователя в зависимости от того, что используется на сайте? Например. один логин для незарегистрированных пользователей, читающих материалы только для чтения. и тот, у кого есть доступ к своим собственным членам, чтобы изменить свое имя, адрес и т. д., а другой — для административного доступа? - person george melinda; 22.01.2011
comment
Вот именно, и конечно, первый пользователь должен получить только права в БД на чтение определенных таблиц. Второй должен уметь читать одни таблицы и писать в другие (но и только в те, которые нужны дизайну вашего приложения). Это, конечно, делает его немного менее гибким во время разработки, но должен быть какой-то компромисс, верно? :П - person Cray; 22.01.2011
comment
Да, ты прав. всякий раз, когда я разрабатывал две вещи, которых мне всегда не хватало, и я думаю, мне было лень это делать, это никогда не закрывать соединение, когда оно было сделано, и использовать только одного пользователя БД со всеми правами. это слишком много работы с этим методом, но что бы ни делало его более безопасным и менее головной болью позже :) - person george melinda; 22.01.2011

используя другое расширение файла, отображаемое пользователю, а не php, aspx и т. д.

блокировка ping/запросов информации о сервере/apache и версии.

Использование Apache AddHandler для запуска php под .html (или любым другим расширением файла) может быть забавным, чтобы сбить с толку любителей scriptkiddies, но любому, кто знает, что они делают, не должно быть трудно выяснить, какую модель сервера вы используете. различные другие тычки и пруфы...

шифрование паролей пользователей с помощью sha1 или шифрование с помощью соли (никогда не мог понять это)

Посолить ваши хэши паролей легко. Вы пишете сценарий, который запускает пароль, а также «ключ», который варьируется для каждого пользователя с помощью метода шифрования, такого как sha1, и этот хэш сохраняется в базе данных. Когда пользователь входит в систему, введенный им пароль проходит через тот же сценарий, и хэши сравниваются. Назначение «ключа» в том, что даже если у 2 пользователей одинаковый пароль, их хэши все равно будут разными из-за разных ключей. Однако вместо хранения хэш-ключей я считаю, что лучше использовать более сложный скрипт, который смешивает имя пользователя и пароль с несколькими шифрами, такими как этот:

$hash = sha1(substr(sha1($password), 0, strlen($_POST['password'])).substr(sha1($loginUsername), 0, (40-strlen($_POST['password']))));

который шифрует пароль, шифрует имя пользователя, использует длину строки пароля, чтобы определить, как объединить подстроки двух хэшей sha, а затем снова шифрует всю строку. Это может показаться немного чрезмерным, но черт возьми, никто не сможет взломать это, даже если они знают имя пользователя и связанный с ним хеш.

не хранить информацию о кредитной карте локально

на самом деле я считаю, что по закону вам не разрешено хранить номера кредитных карт, только последние 4 цифры и хэш номера кредитной карты. Мне никогда не приходилось иметь дело с транзакциями по кредитным картам, но это то, чему нас учили на уроках электронной коммерции, которые я прошел несколько семестров назад.

что касается очистки ввода, когда мне нужно что-то помимо mysql_real_escape_string, я обычно пишу свой собственный скрипт проверки регулярных выражений в зависимости от ожидаемого ввода...

person WebChemist    schedule 22.01.2011
comment
тот $хэш, который вы создаете. вы создаете таблицу, в которой вы идентифицируете каждого пользователя по этому хэшу через сеанс, который им дан, а не вводите туда имя пользователя. или вы шифруете имя пользователя и пароль с помощью этого шифрования в базе данных? - person george melinda; 22.01.2011
comment
В моей пользовательской таблице я храню имя пользователя в виде простого текста (оно использовалось в нескольких других местах на сайте) и хэш из 40 символов. Шифрование имени пользователя не требуется, даже если база данных будет украдена, сложность хэша в значительной степени гарантирует, что они не смогут реконструировать пароль (даже если они получили хеш-функцию, хэш содержит только частичную строку пароля). ша). Когда пользователь входит в систему, он запускает хеш-функцию для предоставленного имени пользователя и пароля и проверяет соответствие имени пользователя и хеш-суммы в базе данных. - person WebChemist; 24.01.2011