Czy jeżeli mamy bezpieczne linki przy użyciu .htaccess to nie jesteśmy narażeni na ataki sql ?

jesli sa dobrze skonstrulowane reguly to zawsze zmniejsza to ryzyko ataków. jednak 100% bym nie obstawial

A od kiedy linki dzielą się na bezpieczne i niebezpieczne? Adres URL to nic innego jak ciąg znaków przekazywany do serwera, który w zależności od jego zawartości zwraca odpowiednią treść.

Tak więc SQL Injection nie ma nic wspólnego z konfiguracją w .htaccess - więcej tutaj...

tak tylko trzeba pisać rozwazne reguly taki maly link


// up

jesli zmienne z url trafiaja bezposrednio do zapytania to maja duzo do sqli

troche nie rozumiem twojej wypowiedzi. Dlaczego nie ma nic wspólnego? Moim zdaniem ma!
Jesli w regule ustawie ze tylko liczby albo tylko takie litery to jest to swego rodzaju zabezpieczenie

To jest pozorne zabezpieczenie, bo w pewnym momencie będziesz prosił użytkownika o wprowadzenie danych (np. podczas logowania) i przekazując całość przez POST będziesz musiał odpowiedniej filtracji dokonać bezpośrednio w skrypcie, a nie regułami w .htaccess.

A co zrobi twoja reguła kiedy wyrażenie będzie sprzeczne? Za każdym razem przekieruje użytkownika na stronę główną lub statyczną stronę z błedem (bo nadal nie wiesz gdzie tkwił błąd)?

hmm z tego co zauważyłem to mówimy o linkach a nie o danych przesyłanych POSTem

Była mowa o wpływie .htaccess na SQL Injection, więc czemu POST miałoby to nie obejmować? Zabezpieczeń nigdy za wiele, a wystarczy jedno zdanie typu "htaccess zabezpiecza w 100% przed SQL Injection" i zaraz wszyscy zieloni w PHP przestaną filtrować dane wejściowe.

wiec raczej mowa o linkach

A POST również korzysta z linków, bo formularz musi zostać gdzieś przekierowany. Chciałem po prostu aby w temacie pojawiła się informacje, że nawet jeśli coś przejdzie przez reguły .htaccess nie oznacza to, że dane są bezpieczne i nie mogą spowodować SQL Injection.

Hmm..ale jeżeli są tzw "przyjazne linki" to chyba nie ma jak użyć ataku sql injectjon.. i bełdzio dzięki za reguły

Bo mam na stronie sporo zapytać do bazy i nie wiem czy jest sens zabezpieczać każde zapytanie, czy lepiej dodatkowych reguł .htaccess

A co to POST to przecież jak ktoś wpisze złośliwą komendę ? W pole formularza np ?

no tak korzysta z linkow i wlasnie o nie chodzi to ze przy okazji leca dane POSTem nie ma nic do rzeczy bo autorowi topiku chodzi o same url, a nie o dane z POSTa

Co do linków jak masz dobre reguły to Ci wystarczy...

A posty, to tak np w formularz...

PS możesz dać "Pomógł" osobom które Ci pomogły, wynagrodzisz je... ;p

A jak zabezpieczyć POST przez sql injectjon ? ShadowD, spoko, dam, zawsze daję

@ShadowD

Nie zgadzam się z tym co piszesz - delikatnie mówiąc.

Jak napisał bełdzio "mod_rewrite jako pierwsza linia obrony przed wstrzyknięciami."

Poza tym co to za pomysł żeby uzależniać aplikację od mod-rewrite... A jak klient zmieni reguły? Albo je wyłączy?

No np. jak masz nick to sprawdzasz czy ma między 3 a 16 znaków i czy zawiera jakieś inne znaki niż a-z, A-Z, 0-9, -. i z tych znaków nikt Ci nic nie zrobi...

@LonelyKnight - Osobiście to ja w ogóle nie stosuje mod_rewrite do zabezpieczeń a przynajmniej die do filtrowania danych, ale skoro się pytali to odpowiedziałam.
Jak dam wyrażenie na a-z, A-Z, 0-9, -. to nikt mi nic nie zrobi przez GET. Skończmy ten temat. (o GET)

A jak masz np. tytuł komentarza? Też wykluczysz np. " ?

Takie podejście jest bardzo kiepskie.

Prosiłem nie wraca ale odpowiem, nie dał bym tytułu tylko ID tematu/komentarza.

Pisałem również że ja tak nie robie ale jeśli będą liczby/litery/- to będzie działało...

dobra rozwiazmy jedna kwestie z linkami mozna bawic sie z rewrite, z danymi przesylanymi od usera nie, po to jest milion funkcji do filtracji danych zeby z nich korzystac spod php i koniec

Ja nie mówiłem o wyciąganiu informacji z bazy ale o ich umieszczeniu w bazie.



A dlaczego mam do tego nie wracać? Nie Ty zakładałeś temat, piszesz coś z czym się nie zgadzam więc ciągnę temat bo może czegoś nie wiem.

Wracając do tematu

Podstawowa sprawa w kwestii bezpieczeństwa to tzw. Defense in Depth. Chodzi o to, że nie można opierać się na jednym zabezpieczeniu ale duplikować te zabezpieczenia aby postawić kolejne "mury" przed agresorem. To, że nie wiesz jak przeprowadzić atak SQL Injection używając np. wyłącznie liter i cyfr nie znaczy, że nie da się tego zrobić albo nie znaczy to, że za 2 czy 6 miesięcy nie będzie można tego zrobić. Mod_rewrite to takie same zabezpieczenie jak np. nakładanie limitów na długość wejścia. Utrudnia ale nie wyklucza.

Czy tak czy tak uważam osobiście, że podstawą jest walidacja danych po stronie skryptu. Stronę z mod rewrite można wywoływać przecież też bezpośrednio (pewnie, obejść się da, ale po co tworzyć nadmierną ilość reguł), jeśli ma się pojęcie jakie zmienne są przesyłane przez adres, poza tym walidacja zawsze się przydaje.

OMG ;p

Trochę się to rozrosło...

Ja uważam tak, modrewrite używam tylko do przyjaznych linków, blokady przed kradzeniem plików graficznych, ustawianie strony głównej i tyle...

Może tak podsumuję:
Zawsze powinno się sprawdzać za pomocą skrypty czy zmienna istnieje (isset) czy nie jest pusta (empty) i czy jeśli ma być np liczbą to czy nią na pewno jest, lub jeśli ma być nick to czy składa się z liter cyfr czy też myślnika. Jednym słowem zawsze sprawdzaj co znajduje się w zmiennej którą użytkownik może podać/zmienić zanim przekażesz ją do np zapytania do bazy...

Moje zdanie na powyższy temat, nic więcej, nic mniej...

Jeszcze coś? ;p

warto korzystac z

[PHP] pobierz, plaintext 
<?php
[b]mysql_escape_string();
?>
[PHP] pobierz, plaintext 

[/b]

- oczywiście, że tak. Bo kto mi zabroni zamiast artykul,3456.html wpisać kat=artykul&id=UNION coś tam? Nie mówiąc już o tym, że mogę próbować wpisywać bezpośrednio...

Generalnie podejście powinno być takie, że najpierw określa się "obszar", do którego użytkownik ma mieć dostęp, a dopiero potem pozwala mu się łaskawie skorzystać z tego obszaru. Ale dziś każdy łatwo i prosto: include($_GET['strona']) i pojechali.

Prosty przykład: masz np. 5 plików 1.php, 2.php itd, które chcesz includować na podstawie zmiennych GET. Zwykły skrypciarz będzie próbował jakiś filtracji-estrakcji etc., natomiast człowiek myślący zrobi sobie najpierw tablicę z tych plików i sprawdzi, czy plik=zlykod.php istnieje w tej tablicy zanim cokolwiek na stronie wyświetli. Zawęziliśmy obszar do tych 5-ciu konkretnych plików i teraz może nam hakier naskoczyć.