Forum PHP.pl

Jeśli nie filtrujesz danych wejściowych, to jest niebezpieczne.

Jeśli filtrujesz, nie przejmuj się; chyba każdą stronę skanują boty poszukujące dziur. ;]

Co sądzicie o tym: http://hacking.pl/5845
Czy coś takiego wystarczy?

A chociaż przeczytałeś ten wątek od początku...?

ostatnich kilka dni przesiedziałem na szukaniu dobrego i skutecznego sposobu zabezpieczenia się przed SQL injection, jednak nic na prawdę konkretnego nie znalazłem;/
pewnie ameryki nie odkryłem, do optymalnych sposobów to nie należy, ale po połączeniu pomysłów z kilku stron oraz fragmentów kodów z tego forum powstało coś takiego:

[PHP] pobierz, plaintext 
<?php
function filtr_sprawdzenie($text)
{
    $filtr_sprawdzenie= filtr($text);
    return substr_count($filtr_sprawdzenie, '1');
}
function filtr($text)
{
    $text=strtolower($text);
    
    
    $ciag_sprawdzenie = substr_count($text, 'unique').
    substr_count($text, '*/').
    substr_count($text, '/*').
    substr_count($text, '//').
    substr_count($text, '#').
    substr_count($text, '<!--').
    substr_count($text, 'char').
    substr_count($text, 'BETWEEN');
 
    return $ciag_sprawdzenie;
    
}
 
 
 
function strip_tags_content($text, $tags = '', $invert = FALSE) { 
preg_match_all('/<(.+?)[s]*/?[s]*>/si', trim($tags), $tags);
  $tags = array_unique($tags[1]);
  if(is_array($tags) AND count($tags)> 0) {
    if($invert == FALSE) {
      return preg_replace('@<(?!(?:'. implode('|', $tags) .')b)(w+)b.*?>.*?</1>@si', '', $text);
    }
    else {
      return preg_replace('@<('. implode('|', $tags) .')b.*?>.*?</1>@si', '', $text);
    }
  }
  elseif($invert == FALSE) {
    return preg_replace('@<(w+)b.*?>.*?</1>@si', '', $text);
  }
  return $text;
}
 
function dlugosc_ciagu($text, $max)
{
    if(strlen($text)<$max)
    {
        return $text;
    }
    else
    return'error';
}
 
$text=$_POST['jakis_tekst'];
$user_id=1;
$max=50;
if(dlugosc_ciagu($text, $max)!='error')
{
    $ile_podejrzanych_znakow = filtr_sprawdzenie($text);//sprawdza czy nie zostało użyte słowo unique itp. jeśli bedzie 1 albo wiecej to ktos chce sie wlamac, jesli 0 to nie:)
    if($ile_podejrzanych_znakow>0)
    {
        echo 'Próba włamania, Twoje IP zostało zbanowane, a admin poinformowany drogą mailową';//dalej kod wysyłający maila/smsa do admina, banujący dane IP w systemie
    }
    else
    {
        $text = strip_tags_content(htmlspecialchars(strip_tags(html_entity_decode(substr($text,0,550)))));
        $zapytanie = "INSERT INTO notatki (`id`, `user_id`, `tresc`) VALUES ('', '$user_id', '$text')";
        $dodaj_komentarz = mysql_query($zapytanie);
    }
}
else
print 'Wpis jest za długi';
?>
[PHP] pobierz, plaintext 

osobiście widzę w tym jeden plus, bo po pierwszej próbie włamania dany użytkownik/bot jest banowany, komunikat o tym jest wysyłany do mnie, a w razie gdyby zaszła pomyłka mogę zdjąć bana z danego użytkownika. Cała strona którą teraz piszę jest dostępna dopiero po zalogowaniu więc goście nie będą mogli nic nabroić(teoretycznie).

geniuszem nie jestem jeśli chodzi o php, dopiero zaczynam w tym zabawę, ale pytanie:
czy ten kod jest dość bezpieczny? ciężko będzie to obejść?
Pozdrawiam Fantome:)

A chociaż przeczytałeś cały ten wątek...?

żeby tylko ten... ze 2 dni temu to czytałem i postanowiłem szukać dalej... jest sporo pomysłów i rozwiązań w tym temacie, ale nikt nie potwierdził, że któreś z podanych zabezpiecza stronę w 100%...

A wiesz o tym, że na nic nie ma 100% zabezpieczenia?

zdaję sobie z tego sprawę jednak staram się wyeliminować jak najwięcej dziur w tym co piszę
pozdrawiam Fantome

Jeśli wprowadzisz to, o czym mowa w tym wątku, nie powinno być problemu.

Zresztą, od tego są beta-testy, aby wyeliminować błędy. [;

Fantome nie banuj po IP - w ten sposób podczas szukania czegoś w google odkryłem już dwa fora internetowe, na których jestem zbanowany po IP a w życiu się tam nie rejestrowałem :/

To raczej nie wina forum, a tego, że IP trafiło prawdopodobnie do kogoś, kto ma PC-zombie.

A z tego, co pamiętam, to TP wykupiła kiedyś pulę IP dla neozdrady, która była wcześniej intensywnie wykorzystywana do włamów. [;

Tak się zastanawiam...
jeśli strona ma geta np id=1, jeśli dopiszemy mu 1' sql /* to nie zareaguje,
ale jeśli mu dam id=aaa to wypluje warning ... czy taka strona jest podatna na sql injection ?
Pytam bo widzę taką stronkę i zastanawiam się czy zawracać gitarę adminowi , dodatkowo ciekawość

Tak. Jeśli dla stringa wypluwa warninga to wielce prawdopodobne jest, że zapytanie jest zbudowane tak:

[SQL] pobierz, plaintext 
SELECT a FROM b WHERE id = $zmienna
[SQL] pobierz, plaintext 

Integery nie muszą być w cudzysłowiach, natomiast stringi tak. A np. zapytanie

[SQL] pobierz, plaintext 
SELECT a FROM b WHERE id = 1' sql /*
[SQL] pobierz, plaintext 

nie wywołuję błędu bo po stronie php są wykrywane pewne niebezpieczne ciągi np. sekwencja "/*" i zmienna jest ignorowana etc.

Jednoznacznie nie da się określić czy taka strona jest podatna na jakiś atak z grupy SQLI. Ja sprawdziłbym ataki typu DoS z grupy SQLI. Sprawdzałbym inne wejścia bo raczej podane przez Ciebie jest popularne.

Taka wskazówka, każdy atak SQLI zaczyna się od wydedukowania zapytania.

Mam pewne pytanie, odnośnie wypowiedzi erixa dotyczącej mysql_escape_string:



Kiedy może się coś takiego stać? Powiedzmy że przez $_POST idzie ciąg, po którym szukam czegoś w bazie w polu typu varchar.
Ciąg z założenia powinien być obrobiony tzn. bez znaków diaktrycznych itp. więc nie muszę się martwić o problemy z nimi.

Chodzi o to, że mysql_real_escape_string działa znacznie wolniej niż wersja bez sprawdzania charsetu.

Np. przy korzystaniu z UTF-8.

Wszystko jest przecież napisane:


A tak poza tym, dla mysql_escape_string" title="Zobacz w manualu PHP" target="_manual:

Hej,

Już raz wspominałem o zastosowaniu zmiennych związanych, ale jakoś widzę wątek dalej rozwija się
w stronę doktoryzacji nad zupełnie prostym problemem. W telegraficznym skrócie:
Zmienne związane mają 2 główne zastosowania:
1) optymalizacja działania aplikacji poprzez jednokrotną interpretację zapytania, a w każdym
następnym jego uruchomieniu tylko podmienianie samych danych. MySQL optymalizuje sobie
niestety takie zapytanie tylko w obrębie sesji. Inne bazy takie jak ORACLE przechowują plan wykonania
zapytania.
2) Oddzielenie treści zapytania od parametrów załatwia przy okazji właśnie problem MySQL Injection.
W zasadzie w 100% ponieważ dane nie wpływają na treść zapytania, która już wcześniej została sparsowana.

Przykład SQLa:

[SQL] pobierz, plaintext 
SELECT * FROM tabela WHERE pole = :parametr
[SQL] pobierz, plaintext 

takie zapytanie parsuje sobie baza, a dopiero potem przekazujemy (bindujemy) wartość
zmiennej "parametr".

Jeszcze raz link do manuala PHP:
PDO::prepare
oraz jak kto woli:
mysqli_prepare

Oczywiście warunkiem jest PHP5 oraz MySQL 4.1, ale to chyba już w tej chwili standard.

Z tego co zauważyłem to ile osób tyle rozwiązań przed tego typu atakami. A jeżeli ktoś opracuje jakiś uniwersalny kod - to posypie się sporo wypowiedzi negatywnych. Wiec z tego nasuwa się jeden wniosek, jakie zabezpieczenie by nie było i tak nie jest dobre.

Z tego co czytałem ten wątek i jemu podobne w sieci. To nasuneły mi sę takie spostrzeżenia:
Przed atakami XSS najlepiej się bronić stosując htmlspecialchars lub htmlentities - dla danych wyświetlanych (np z BD).


Natomiast przed SQL Injecton, to albo zapoznać się z jakimś interfejsem np PDO i konstruować zapytania w stylu prepare, execute. 
Ale jeżeli ktoś chce zostać przy standardowym konstruowaniu zapytań do BD (np nie chce mu się przebudowywać istniejącego serwisu pod PDO), to czy nie wystarczy dane (zewnętrzne) czy to z POST czy GET poddawać najpierw np htmlentities potem zastosować sprawdzanie wyrażeniami regularnymi (lub stosować funkcje ctype, is_numeric itp.), a na końcu w zapytaniu do BD zastosować mysql_real_escape_string

Jest wiele opini na temat czy to htmlentities, addslashes, strip_tags. Ale które nalepsze? 

strip_tags - wycina(eliminuje) znaczniki HTML,
- nie warty zachodu, jeżeli dane które mają być przetworzone, zapisane w BD a potem wyświetlane w serwisie (stracą formatowanie). 
- jednak są sytuacje w których może się przydać.


addslashes - Dodaje znak ucieczki przed znakami niebezpiecznymi jak: apostrof, cudzysłów, backslash i NUL

htmlentities - konwertuje wszystkie znaki HTML na encje, gdzie htmlspecialchars tylko znaki specjalne. 

Wiec jeżęli ciag zostanie przeformatowany przez htmlentities - to spokonie można sprawdzić np wyrażeniami regularnymi czy zawiera to co powinnien i odpowiednią długość znaków, a następnie przekazać do bazy danych. Ale czy warto wtedy stosować mysql_real_escape_string? - moim zdaniem warto na wypadek gdy wyrażenia regularne nie będą zbyt ścliśle określone i przepuszczą coś w stylu  UNION, SELECT ... Wówczas jeżeli dobrze rozumie powyższa komenda to wyeliminuje.

Ale nie jestem specem w tej dziedzinie i miło mi będzie jeżeli ktoś to sprostuje.

Wszystkie pytania o SQL Injection powinny się kończyć jednym zdaniem: "Używaj prepared statements, lub jeśli uważasz, że nigdy nie zapomnisz tego zrobić, dodawaj znaki ucieczki odpowiednie dla twojej bazy". Koniec, kropka. Podobnie XSS - "usuwasz cały html albo escape podczas wyświetlania".
Tymczasem w tym wątku co chwila pojawiają się jakieś dziwne pomysły, które co najwyżej wprowadzają zamieszanie i w sumie nie wiem czemu ten wątek ma służyć. Może lepiej przyciąć to do jednego postu z informacją co i jak i tylko go zostawić przypiętym?

Zgadzam się. Jak czytam niektóre z tych wymysłów to aż głowa boli. Potem się przyszła ekipa źle nauczy.

ja bym dodał świadomie bo korzystając z PS też można dać ciała