П О Р Т А Л                            
С Е Т Е В Ы Х                          
П Р О Е К Т О В                        
  
Поиск по сайту:
                                                 
Главная

О проекте

Web-мастеру
     HTML & JavaScript
     SSI
     Perl
     PHP
     XML & XSLT
     Unix Shell

MySQL

Безопасность

Хостинг

Другое








Самое читаемое:

Учебник PHP - "Для Чайника".
Просмотров 4098 раз(а).

Иллюстрированный самоучитель по созданию сайтов.
Просмотров 6759 раз(а).

Учебник HTML.
Просмотров 3720 раз(а).

Руководство по PHP5.
Просмотров 5993 раз(а).

Хостинг через призму DNS.
Просмотров 4815 раз(а).

Подборка текстов стандартных документов.
Просмотров 56246 раз(а).

Учебник PHP - Самоучитель
Просмотров 3706 раз(а).

Документация на MySQL (учебник & справочное руководство)
Просмотров 8347 раз(а).

Внешние атаки...
Просмотров 4566 раз(а).

Учебник PHP.
Просмотров 3175 раз(а).

SSI в примерах.
Просмотров 176 раз(а).



 
 
| Добавить в избранное | Сделать стартовой | Помощь





Учебник РНР
НазадГлава 4. Безопасность Вперёд

Сообщение об ошибке

При использовании системы безопасности PHP имеются две стороны сообщения об ошибках.
Одна это преимущества от повышения уровня безопасности, другая - вред.

Стандартная тактика нападения включает профилирование системы для введения в неё несоответствующих данных и проверка вида ошибок и контекста, в котором они возвращаются. Это даёт взломщику системы возможность испробовать информацию о сервере для определения возможных дыр. Например, если взломщик собрал информацию о странице на основе предыдущей отправки формы, он может попытаться переопределить значения или модифицировать их:
Пример 4-11. Атака на переменные HTML-страницей
<form method="post" action="attacktarget?username=badfoo&password=badfoo">
<input type="hidden" name="username" value="badfoo">
<input type="hidden" name="password" value="badfoo">
</form>

Ошибки PHP, которые нормально возвращаются, могут помочь разработчику при отладке скриптов, указывая на такие вещи, как неудачно выполненная функция или файл PHP, в котором была неудача, и номер строки, в которой возникла ошибка. Эта информация и будет использоваться.
Для разработчика php привычно использовать show_source(), highlight_string() или highlight_file() как средство отладки, но на действующем сайте это может обнаружить скрытые переменные, непроверяемый синтаксис и другую опасную информацию. Особенно опасно запускать код из известных источников со встроенными обработчиками отладки или использовать обычную технику отладки. Если хакер сможет определить, какую технику вы используете, он может попытаться грубо форсировать страницу, отправляя разные обычные строки отладки:
Пример 4-12. Использование обычных переменных отладки
<form method="post" action="attacktarget?errors=Y&amp;showerrors=1"&debug=1">
<input type="hidden" name="errors" value="Y">
<input type="hidden" name="showerrors" value="1">
<input type="hidden" name="debug" value="1">
</form>

Независимо от метода обработки ошибок, возможность проверки системы на наличие ошибок приведёт к снабжению хакера дополнительной информацией.

Например, стиль общей PHP-ошибки указывает систему, на которой запущен PHP. Если хакер просмотрит .html-страницу и захочет проверить её (найти известные утечки в системе), заполнив её неправильными данными, он сможет определить, что система построена с PHP.

Ошибка функции может указать, запущена ли на системе конкретная машина БД, или дать ключ к тому, как web-страница сконструирована или запрограммирована. Это позволит глубоко внедриться в открытый порт БД или найти специфический bug или утечку в web-странице.
Вводя разные блоки неверных данных, например, хакер может определить порядок аутентификации в скрипте (по номерам строк с ошибками), а также попробовать использовать то, что может иметься в разных частях скрипта.

Ошибка файловой системы или общая ошибка PHP может указать на то, какие привилегии имеет web-сервер, а также на структуру и организацию файлов на web-сервере. Записанный разработчиком код ошибки может усугубить эту проблему, приведя к лёгкому способу использования ранее "скрытой" информации.

Есть три основных способа решения этой проблемы:

Первый - структурировать все функции и попытаться компенсировать объём ошибок.
Второй - полностью отключить в работающем коде сообщения об ошибках.
Третий - использовать специальные функции PHP по обработке ошибок для создания вашего собственного обработчика ошибок.

В зависимости от используемой вами политики безопасности, вы может применить все три способа в вашей ситуации.

Одним из способов решения этой проблемы является использование собственного error_reporting() РНР, чтобы помочь вам обезопасить ваш код и скрыть использование переменных, которое может представлять опасность. Тестируя ваш код с помощью E_ALL до публикации, вы сможете быстро обнаружить области, где ваши переменные могут оказаться открытыми для модификации другими способами. Если вы уже готовы опубликовать, используя E_NONE вы отключите возможность проверки вашего кода.
Пример 4-13. Обнаружение опасных переменных с помощью E_ALL
<?php
if ($username) {  // не инициализируется или проверяется перед использованием
    $good_login = 1;
}
if ($good_login == 1) { // Если предыдущий тест терпит неудачу, не инициализируется
			//или проверяется перед использованием
    fpassthru ("/highly/sensitive/data/index.html");
}
?>


Назад Оглавление Вперёд
Безопасность БД ВверхИспользование Register_Globals


Если Вы не нашли что искали, то рекомендую воспользоваться поиском по сайту:
 





Copyright © 2005-2016 Project.Net.Ru