REQUEST_URI i mały trik

Czy można ominąć poniższe zabezpieczenie, tak żeby wyświetliło się ‚tajne haslo’ (skrypt nazywa sie config.php)?

<?php
   if ($_SERVER['REQUEST_URI'] == '/config.php') {
      die("nie mozna odwolac sie do tego skryptu bezposrednio!");
   }
   echo 'tajne haslo ';
   //inne tajne dane
?>

Pewnie już domyślacie się odpowiedzi. Wystarczy zamiast config.php wywołać w requescie config%2ephp. Taki mały trik. Zaczerpnięte ze (od niedawna mojej ulubionej) strony suspekt.org. ;]

SQL Column Truncation Vulnerability po polsku

Kiedy dostałem linka od mojego znajomego do notki Stefana Essera na temat ciekawych podatności MySQL, od razu zacząłem testować popularne skrypty pod kątem tego typu błędów. Oczywiście rozpocząłem od WordPress ;] Niestety, najprawdopodobniej nie byłem pierwszy, bo (co w sumie logiczne) Stefan dużo wcześniej przetestował ten skrypt i poinformował o usterce programistów WordPress.

W każdym razie, poniżej postarałem się ująć w kilku przykładach istotę tej klasy podatności.

mysql> CREATE TABLE test (login varchar (20) );
Query OK, 0 rows affected (0.39 sec)

mysql> INSERT INTO test VALUES ( 'admin' );
Query OK, 1 row affected (0.36 sec)

mysql> select * from test;
+-------+
| login |
+-------+
| admin |
+-------+
1 row in set (0.01 sec)

próba wstawienia 21-znakowego ciągu do pola 20 znakowego
powoduje obcięcie i wyrzucenie nadmiaru znaków (czyli
w tym wypadku wyrzucenie znaku 'x')

mysql> INSERT INTO test VALUES ( 'admin               x' );
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> select * from test;
+----------------------+
| login                |
+----------------------+
| admin                |
| admin                |
+----------------------+
2 rows in set (0.00 sec)

mysql> select hex(login) from test;
+------------------------------------------+
| hex(login)                               |
+------------------------------------------+
| 61646D696E                               |
| 61646D696E202020202020202020202020202020 |
+------------------------------------------+
2 rows in set (0.03 sec)

mysql> select * from test where login='admin';
+----------------------+
| login                |
+----------------------+
| admin                |
| admin                |
+----------------------+
2 rows in set (0.02 sec)

mysql> select * from test where login='admin                ';
+----------------------+
| login                |
+----------------------+
| admin                |
| admin                |
+----------------------+
2 rows in set (0.00 sec)

Poza tym MySQL w standardowej konfiguracji ma ustawioną opcje max_packet_size na jeden megabajt. Jest to maksymalny rozmiar pakietu możliwego do przesłania pomiędzy serwerem SQL a klientem. Zatem gdy zapytanie przekroczy tą wartość, nie zostanie w ogóle wykonane. Najczęściej spowoduje to błąd w aplikacji webowej która wykona takie query.

Poprzez odpowiednią manipulację rozmiarem danych, można doprowadzić do sytuacji w której część zapytań nie wykona się, właśnie z powodu przekroczonego rozmiaru zapytania, a część z zapytań wykona się normalnie. W konsekwencji aplikacja może np. przestać działać poprawnie, utworzyć błędy bypass, w ogóle przestać działać itp.

szukanie błędów

niewątpliwie ciekawe zajęcie, choć czasami frustrujące. najbardziej nie lubie znajdywać błędów przez które właściwie mało co można zdziałać np. takie full path disclosure. rzadko kiedy informacje zdobyte tą drogą prowadzą do krytycznych nadużyć. Wpis inspirowany znalezionym błędem full path disclosure w najnowszej Joomli. Screen na dowód żeby nie było że pisze bajki (sory za mało przyjazną cenzure, miałem pod ręką tylko painta ;p)

WordPress 2.6.1 SQL Column Truncation Vulnerability

Opublikowane na milw0rm. Na dniach postaram się napisać coś więcej apropo tej klasy podatności. Jeżeli chcesz wiedzieć więcej teraz, przeczytaj notke (po angielsku) na blogu Stefana Esser’a.