Jump to content
ТУК НЕ СЕ ПРЕДЛАГАТ ХАКЕРСКИ УСЛУГИ ! ×

Уникална защита против Directory Traversal на PHP


Recommended Posts

Преди ден-два преглеждах кода на един сайт и срещнах ей това злато.

kerXZwC.png

 

Доста смешно е, когато разбереш защо скрипта не прави абсолютно нищо.

Дори и на мен ми отне минутка да разбера защо нищо не прави, но вярвам, че все някой ще го разгадае.

Edited by Hexagone
Link to comment
Share on other sites

Подай му следния input и гледай магията :)

...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./etc/passwd

 

Много лесно може да се прескочи тоя чек :), евала на devs

Бирата я искам по пощата.

Edited by d3k4z
Link to comment
Share on other sites

Прав си че не съм догледал че INPUT-a ще се върне същия, но когато видиш такова нещо по време на blackbox test --> тези 'глупости', както ги реферираш ще евейднат контрола(ако той работеше) - така че референцийте си ги сдържай.

Link to comment
Share on other sites

7 minutes ago, d3k4z said:

Прав си че не съм догледал че INPUT-a ще се върне същия, но когато видиш такова нещо по време на blackbox test --> тези 'глупости', както ги реферираш ще евейднат контрола(ако той работеше) - така че референцийте си ги сдържай.

Изглежда съм те обидил, не беше тва моето намерение, но няма значение.

Link to comment
Share on other sites

В първия ред имаме преобразуване на ".." (две точки) в "" (празен символ),  след което същото се повтаря ("%2е%2е" = ".." -> "") но в друга кодировка. 

Символният низ "%2е"  е  точка "." (поне така е записано в RFC 3986 ).

 Ако имаме нещо от рода: text..%2e%2e001 и приложим функцията ще получим резултат: text001 (сините и оранжевите символи се елиминират).

Лично за мен не е желателно, ако имаме  относително зададен път към конкретен файл да изчистваме "..", но това е мое мнение. Визирам замяна от рода "../MyPicture/PNG/Pic_001.png" в "/MyPicture/PNG/Pic_001.png" примерно. Защо е нужно да се прави?  Ако го направим вече указваме различен път.

Ако изпълним 

sanitize  ("...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./etc/passwd")

ще получим:

"../../../../../../../../../../etc/passwrd"

Трите точки се трансформират в точка, %2е%2е се елиминират и последната точка остава и получаваме файла. Тук определено d3k4z не само е прав, но и заслужава две големи бири. Аз лично нямаше да се сетя за това.

 

Ако не ме лъже паметта /etc/passwrd (файл съдържащ потребителските акаунти) е нещо задължително за за POSIX операционните системи, но признавам чистосърдечно, че нищо не разбирам от UNIX и Linux.

Според мен това е начин да се осъществи защита от заявки, съдържащи "/\../"..

Ако е така мисля, че в скрипта могат да се внесат подобрения. 

От друга страна подобен вид атаки (излизане извън рамките на разрешената директория и получаване на несанкциониран достъп до определен файл) при Windows се извършват под друга форма. Там операционната система има различна логика (визирам логическите устройства).

Подобен подход се използва при SAP порталите, когато трябва да се предпазим от  !252f..!2!252f..!252f52f, но е по-лесно просто да се обърне внимание на 1630293?

Извинявайте, че се намесвам, но не искам да се карате.

Обяснете на стареца, какво пропуска, моля.

 

Edited by Avatara
  • Like 2
Link to comment
Share on other sites

ЗА ЛЮБОПИТНИТЕ:

В първия ред имаме преобразуване на ".." (две точки) в "" (празен символ),  след което същото се повтаря ("%2е%2е" = ".." -> "") но в друга кодировка. 

Символният низ "%2е"  е  точка "." (поне така е записано в RFC 3986 ).

Ако имаме нещо от рода: text..%2e%2e001 и приложим функцията ще получим резултат: text001 (сините и оранжевите символи се елиминират).

 

ЗА СПОРЕЩИТЕ:

Ако изпълним 

sanitize  ("...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./etc/passwd")

ще получим:

"../../../../../../../../../../etc/passwrd"

Трите точки се трансформират в точка, %2е%2е се елиминират и последната точка остава и получаваме файла.

Тук определено d3k4z не само е прав, но и заслужава две големи бири.

Аз лично нямаше да се сетя за това.

Ако не ме лъже паметта /etc/passwrd (файл съдържащ потребителските акаунти) е нещо задължително за за POSIX операционните системи, но признавам чистосърдечно, че нищо не разбирам от UNIX и Linux.

Що се отнася до въпроса на Hexagon ...

Според мен това е начин да се осъществи защита от заявки, съдържащи "/\../"..

Ако е така мисля, че идеята е изключително оригинална.

Поздравления за Hexagon и две големи бири за находката

Хубаво (ако е възможно) в скрипта  да се внесат малки подобрения, които биха го направили брилянтен.

От друга страна подобен вид атаки (излизане извън рамките на разрешената директория и получаване на несанкциониран достъп до определен файл) при Windows се извършват под друга форма. Там операционната система има различна логика.

Подобен подход се може да бъде използван и при SAP порталите, когато трябва да се предпазим от  !252f..!2!252f..!252f52f,  там където по някаква причина не може да гарантираме манипулация на нота 1630293.

 

 

Извинявайте, че се намесвам, но не искам да се карате. По-добре е да се почерпим. :$

Обяснете на стареца, какво пропуска, моля.

Edited by Avatara
Link to comment
Share on other sites

4 minutes ago, Avatara said:

ЗА ЛЮБОПИТНИТЕ:

В първия ред имаме преобразуване на ".." (две точки) в "" (празен символ),  след което същото се повтаря ("%2е%2е" = ".." -> "") но в друга кодировка. 

Символният низ "%2е"  е  точка "." (поне така е записано в RFC 3986 ).

Ако имаме нещо от рода: text..%2e%2e001 и приложим функцията ще получим резултат: text001 (сините и оранжевите символи се елиминират).

 

ЗА СПОРЕЩИТЕ:

Ако изпълним 

sanitize  ("...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./...%2e%2e./etc/passwd")

ще получим:

"../../../../../../../../../../etc/passwrd"

Трите точки се трансформират в точка, %2е%2е се елиминират и последната точка остава и получаваме файла.

Тук определено d3k4z не само е прав, но и заслужава две големи бири.

Аз лично нямаше да се сетя за това.

Ако не ме лъже паметта /etc/passwrd (файл съдържащ потребителските акаунти) е нещо задължително за за POSIX операционните системи, но признавам чистосърдечно, че нищо не разбирам от UNIX и Linux.

Що се отнася до въпроса на Hexagon ...

Според мен това е начин да се осъществи защита от заявки, съдържащи "/\../"..

Ако е така мисля, че идеята е изключително оригинална.

Поздравления за Hexagon и две големи бири за находката

Хубаво (ако е възможно) в скрипта  да се внесат малки подобрения, които биха го направили брилянтен.

От друга страна подобен вид атаки (излизане извън рамките на разрешената директория и получаване на несанкциониран достъп до определен файл) при Windows се извършват под друга форма. Там операционната система има различна логика.

Подобен подход се може да бъде използван и при SAP порталите, когато трябва да се предпазим от  !252f..!2!252f..!252f52f,  там където по някаква причина не може да гарантираме манипулация на нота 1630293.

 

 

Извинявайте, че се намесвам, но не искам да се карате. По-добре е да се почерпим. :$

Обяснете на стареца, какво пропуска, моля.

Ти пък нацяло изтърва смисъла :D:D:D

Въпроса е, че се използва str_replace, ама не заменя променливата $name.

Демек нищо не заменя.

Иначе и на тебе една бира, за това, че искаш да помогнеш.

Link to comment
Share on other sites

Пак моля да бъда извинен. 

ЗА ЛЮБОПИТНИТЕ

Би било правилно да се напише:

private function sanitize ($name){

  $name = str_replace("..", "", $name);

  $name = str_replace("%2e%2e", "", $name);

  return $name;

}

(да благодарим на LinuxMaster, за забележката )

 

Мисля, че това е недостатък на съвременните скриптови езици. Вероятно програмистът е свикнал да изписва нещо от рода на:

str.replace(str.begin()+12, str.end()-4, 4, 'о');

и това го е подвело. Едва ли би допуснал подобна грешка, ако се бе научил да ползва:

after:= StringReplace (before, ' a ', ' THE ', [rfReplaceAll, rfIgnoreCase]);

 

ЗА ЕКСПЕРТИТЕ

Използването на str_replace Може да има доста широк спектър на приложение.

<?php 
function str_replace_json($search, $replace, $subject){ 
     return 
json_decode(str_replace($search, $replace json_encode($subject))); 

} 

?> 

както и работата със символни низове и обекти.

function cleandata($data) { 

$data = preg_replace("#(https:\/\/)#",'',$data); 
$data = preg_replace("#(http:\/\/)#",'',$data); 

return $data; 

 

class Obj {
    public 
$x;
}

function 
obj_inc_x($obj) {
    
$obj->x++;
    return 
$obj;
}

Отново се извинявам на всички. Понякога допускам глупави грешки. 

Така и не разбрах каква е разликата между return($data); и return $data; или = и ->

Когато беше със скоби се връщаше резултата или нещо такова. Да, де ама от друга страна return в PHP беше езикова конструкция. Със скоби или без - все тая.

Не мога да се оправя и това е. :$

Edited by Avatara
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.