Шрифт:
□ Не «зашивайте» ключи в код и ни в коем случае не думайте, что XOR с фиксированной строкой можно считать механизмом шифрования.
□ Не игнорируйте вопросы защиты данных в сети.
Стоит подумать
□ Об использовании технологий уровня сети, способных еще уменьшить риск. Речь идет о межсетевых экранах, виртуальных частных сетях (VPN) и балансировании нагрузки.
Грех 9. Применение загадочных URL и скрытых полей форм
В чем состоит грех
Представьте себе сайт, где вы можете купить машину по той цене, которую сами предложите! Такое возможно, если цена машины будет храниться в скрытом поле формы. Напомним, что ничто не может помешать пользователю просмотреть содержимое документа, а затем отправить серверу измененную форму, в которой цена будет «несколько» снижена (легко написать такой сценарий, например, на Perl). Скрытые поля в действительности скрытыми не являются.
Еще одна распространенная ошибка связана с «загадочными URL»: многие Web–приложения хранят в URL информацию об аутентификации и другие важные данные. В некоторых случаях эти данные нельзя выставлять на всеобщее обозрение, поскольку противник может их перехватить и начать манипуляции с сеансом. В иных случаях загадочный URL применяется как особая форма контроля доступа взамен общепринятых систем на базе проверки верительных грамот (credentials). Другими словами, пользователь предъявляет системе свой идентификатор и пароль, и в случае успешной аутентификации та создает строку, представляющую данного пользователя.
Подверженные греху языки
Уязвим любой язык или технология, применяемые для создания Web–сайтов, например: PHP, Active Server Pages (ASP), C#, VB.NET, J2EE (JSP, сервлеты), Perl и CGI (Common Gateway Interface – общий шлюзовой интерфейс).
Как происходит грехопадение
С этим грехом связаны две разные ошибки, которые мы и рассмотрим поочередно.
Загадочные URL
Первая ошибка – это использование загадочных URL (Magic URL), содержащих либо секретную информацию, либо нечто, что может дать противнику доступ к секретной информации. Взгляните на следующий URL:
Интересно, что за строка следует после id. Вероятно, она представлена в кодировке base64; на это указывает небольшой набор ASCII–символов и завершающие знаки равенства. Если подать эту строку на вход декодера base64, то он тут же вернет расшифровку: «My$ecre+pA$$wOrD». Нет сомнений, что это «зашифрованный» пароль, а в качестве алгоритма этого с позволения сказать шифрования выступает base64! Не поступайте так, если ваши данные представляют хоть какую–то ценность.
Следующий фрагмент кода на языке С# показывает, как легко производятся Ьа5е64–кодирование и декодирование:
string s = «<some string>»;
string s1 = Convert.ToBase64String(UTF8Encoding.UTF8.GetBytes(s));
string s2 = UTF8Encoding.UTF8.GetString(Convert.FromBase64String(s1));
Короче говоря, хранить секретные данные в URL либо в теле HTTP–запроса или ответа – грех, если только полезная нагрузка не защищена криптографическими средствами.
Следует принять во внимание характер конкретного Web–сайта. Если данные, передаваемые в составе URL, используются для аутентификации, то, скорее всего, безопасность под угрозой. Впрочем, если сайт использует эти данные для определения членства в сообществе, то, может быть, ничего страшного и не случится. Все зависит от того, что именно вы пытаетесь защитить.
Представьте себе следующий сценарий. Вы создали и хотите продать сайт для организации фотогалерей, позволяющий пользователям загружать снимки, сделанные во время отпуска. Такая система может считаться основанной на членстве, поскольку фотографии, скорее всего, не секретны. Но допустим, что некий злоумышленник (Маллет) перехватил верительные грамоты другого пользователя (Дэйва) (имя, пароль или опознавательную строку), передаваемые в составе URL или полезной нагрузки. Тогда Маллет сможет отправить серверу от имени Дэйва запрос, в котором на сайт загружается порнографическое изображение. С точки зрения любого пользователя системы, картинка пришла от Дэйва, а не от Маллета.
Скрытые поля формы
Другая ошибка заключается в передаче важной информации от приложения клиенту в скрытом поле формы в надежде, что клиент (1) не сможет ее увидеть и (2) не сможет ей манипулировать. Но злоумышленнику ничего не стоит прочитать все, в том числе и скрытое, содержимое формы с помощью операции просмотра исходного HTML–кода, имеющейся в любом браузере, а затем отправить серверу поддельную форму с измененными значениями скрытых полей. Сервер понятия не имеет, кто выступает в роли клиента: браузер или Perl–сценарий! В представленных ниже примерах такая угроза безопасности разъясняется подробнее.
Родственные грехи
Иногда Web–разработчики совершают и другие грехи, в частности описанный под заголовком «Загадочные URL». Суть этого греха состоит в использовании негодных методов «шифрования».
Где искать ошибку
Искать нужно места в программе, где:
□ Web–приложение получает секретную информацию из формы или из URL;
□ для принятия решения о безопасности, доверии или авторизации используются данные;
□ данные передаются по незащищенному или не заслуживающему доверия каналу.