Защита Web-приложений

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

Вначале начнем с некоторых общих недостатков Web-приложений, которые могут быть проверены относительно легко. Наиболее общим недостатком является, обработка входных данных.

Рассмотрим сценарий проверки регистрационных данных. Допустим, что этот сценарий принимает два параметра – имя пользователя и пароль, методом POST. В исходный код этого сценария можно включить проверку подлинности, а именно:


 $sqlquery="SELECT * FROM USERS WHERE username='$username' AND password='$password'"; 
 if(function_to_perform_query($sqlquery)) 
 { 
 echo “Вы успешно авторизировались”;
 } 
 else { 
 echo “Неправильное имя пользователя или пароль. Ошибка”;
 }
 

Выглядит довольно просто, не так ли? Предположим, что пользователь в поле Логин ввел admin, а пароль ввел:

'a' or 'a'='a

Теперь переменная $sqlquery примет следующие значения:

SELECT * FROM users WHERE username='admin' AND password='a' or 'a'='a'

Если все пройдет успешно, то злоумышленник войдет с правами администратора. Это очевидно! Sql запрос всегда будет возвращать истинное значение из-за дополнительного пункта ‘a’=’a’, которые, конечно, всегда будет правильным, так как значение ‘a’ всегда будет равняться ‘a’.

Другим важным моментом является то, что многие языки программирования поддерживают функции вызова, что позволяет использовать внешние приложения. Многие Web-приложения не выполняют проверку входных данных параметров, которые вызываются, такие как system()

Например:

system ("/bin/echo $i");

Если переменная $i – это параметр принят от пользователя, то злоумышленник может ввести следующее значение:

'cat /etc/passwd'

Это приведет к выполнению следующего вида:

/bin/echo 'cat /etc/passwd'

Показывая тем самым файл, который находиться по пути cat /etc/passwd’, вместо того, что Вы хотели показать.

Для того, чтобы защитить свое приложение, разработчик должен проверять входные данные отфильтровывать их с помощью символов:

' . ; / @ & | % ~ < > " $ ( ) { } [ ] * ! '

Так же потенциально опасно использовать Cookie. Cookie – это часть информации которая загружается на жесткий диск и храниться на компьютере. Пользователь или программы могут изменить их, что уже является небезопасным для Web-приложения. Рассмотрим Cookie со следующими данными:

lang=en-us; user=joe; time=10:10 EST;

Злоумышленник может изменить эти данные и иметь доступ к более высокой привилегированной учетной записи.

Web-приложение также может поддерживать вложение сессий в URL

http://www.testserver.com/authenticate.cgi?user=john&sessionid=123456789

Для того, чтобы пользователи не могли увидеть нужные данные через URL, я посоветую зашифровывать их с помощью MD5. Это позволит гораздо труднее повторить или скопировать нужные данные.

Также еще используются скрытые элементы. Эти статические элементы содержаться в Web-формах. Они обычно не отображаться в браузерах, а используются только для передачи информации между различными Web-формами через протокол POST. Вот пример скрытого элемента.

<INPUT NAME="example" TYPE=”HIDDE” VALUE="5.25">

Проблемой является то, что злоумышленник может изменить на любое значение которое ему нужно. Представьте себе, что вы используете скрытые элементы в Интернет магазине, который принимает онлайн платежи. Значение example – это сумма к оплате. Если пользователь вместо значение 5,25 напишет например -100, приложение может подумать, что она должна этому клиенту деньги и переведет на его счет 100 у.е.

Для того чтобы защитить свое Web-приложение, не забывайте использовать проверку входных данных. В следующих уроках я еще вернусь к этой теме, и мы рассмотрим другие уязвимые места Web-приложений. А пока на этом все!

Понравился урок? Добавьте его к себе в закладки.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *