Forum PHP.pl

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 !

Ten post edytował mlattari 29.12.2008, 14:42:34

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

Ten post edytował mlattari 30.12.2008, 03:54:05

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

Ten post edytował Ermes 2.01.2009, 22:00:26

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