Известување за грешки

Со PHP безбедност, има две страни на пријавување грешки. Едната е корисна за зголемување на безбедноста, другата е штетна.

Со PHP безбедноста, постојат две страни на пријавување грешки. Едната е корисна за зголемување на безбедноста, другата е штетна.

<form method="post" action="attacktarget?username=badfoo&amp;password=badfoo">
<input type="hidden" name="username" value="badfoo" />
<input type="hidden" name="password" value="badfoo" />
</form>

Пример #1 Напад на променливи со прилагодена HTML страница show_source(), highlight_string(), или highlight_file() PHP грешките што нормално се враќаат можат да бидат многу корисни за развивач кој се обидува да отстрани грешки во скрипта, укажувајќи на такви работи како што е функцијата или датотеката што откажала, PHP датотеката во која откажала и бројот на редот во кој настанал отказот. Ова се сите информации што можат да бидат искористени. Не е невообичаено PHP развивач да користи

<form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;debug=1">
<input type="hidden" name="errors" value="Y" />
<input type="hidden" name="showerrors" value="1" />
<input type="hidden" name="debug" value="1" />
</form>

Пример #2 Искористување на вообичаени променливи за отстранување грешки

Без оглед на методот на ракување со грешки, можноста за испитување на систем за грешки доведува до обезбедување на повеќе информации за напаѓачот. .html На пример, самиот стил на генеричка PHP грешка укажува дека системот работи со PHP. Ако напаѓачот гледал

страница и сакал да го испита задниот дел (за да бара познати слабости во системот), со хранење на погрешни податоци, тие може да утврдат дека системот е изграден со PHP.

Грешка во функција може да укаже дали системот работи со специфичен систем за бази на податоци или да даде навестувања за тоа како е програмирана или дизајнирана веб-страница. Ова овозможува подлабоко истражување на отворени порти за бази на податоци или барање специфични грешки или слабости во веб-страница. Со хранење различни парчиња лоши податоци, на пример, напаѓачот може да го утврди редоследот на автентикација во скрипта (од грешките на бројот на редот), како и да бара експлоатации што можат да бидат искористени на различни места во скриптата.

Системска датотека или општа PHP грешка може да укаже какви дозволи има веб-серверот, како и структурата и организацијата на датотеките на веб-серверот. Кодот за грешки напишан од развивачот може да го влоши овој проблем, што доведува до лесно искористување на порано „скриени“ информации.

Постојат три главни решенија за овој проблем. Првото е да се испитаат сите функции и да се обидат да се компензираат за поголемиот дел од грешките. Второто е целосно да се оневозможи пријавувањето грешки на работниот код. Третото е да се користат функциите за ракување со грешки на PHP за да се создаде сопствен ракувач со грешки. Во зависност од вашата политика за безбедност, можеби ќе најдете дека сите три се применливи за вашата ситуација. error_reporting()Еден начин да се фати овој проблем однапред е да се искористат сопствените E_ALLна PHP, за да ви помогне да го обезбедите вашиот код и да пронајдете употреба на променливи што може да бидат опасни. Со тестирање на вашиот код, пред распоредување, со error_reporting() , можете брзо да пронајдете области каде вашите променливи може да бидат отворени за труење или модификација на други начини. Откако ќе бидете подготвени за распоредување, треба или целосно да го оневозможите пријавувањето грешки со поставување php.ini option display_errorsна 0, или да го исклучите приказот на грешките користејќи error_log , за да го изолирате вашиот код од испитување. Ако го изберете второто, треба исто така да ја дефинирате патеката до вашата датотека за евиденција користејќи log_errors on.