konto usunięte
Michał Jarosz:
Piotr Likus:>@Przemek: to samo możesz osiągnąć na poziomie PHP-a.
Wtedy zamiast "mysql_select" robisz w kodzie "getCustomerOrders()".
No nie jest to do końca to samo. W przypadku procedur składowanych, zapytania przechowywane są w postaci skompilowanej i nijak nie wstawisz do nich własnego SQL.
Michał
Jarosz
Frontend Developer &
Team Leader
konto usunięte
Michał
Stachura
Dedykowane serwisy i
strony www -
http://santri.eu
Wojciech Małota:Odgrzebię nieco temat.
Tak będzie bardziej "jazzy":
$query = $db->prepare('INSERT INTO baza_danych VALUES(:zmienna)');
$query->bindParam(':zmienna', $zmienna, PDO::PARAM_STR);
$query->execute();
W zupełności wystarczające i bezpieczne.Wojciech Małota edytował(a) ten post dnia 14.11.09 o godzinie 20:26
konto usunięte
Wojciech Małota Programista
Michał Stachura:
Odgrzebię nieco temat.
Wojtek jakiego PDO::PARAM_??? używasz dla pól typu 'text'?
Michał
Stachura
Dedykowane serwisy i
strony www -
http://santri.eu
Wojciech Małota Programista
Michał Stachura:
Szkoda. Wiąże się z tym pewna niedogodność ale im bezpieczniej tym niej wygodnie niestety :)
konto usunięte
Krzysztof
Kotowicz
senior web
developer/system
architect,
Freelancing
konto usunięte
Krzysztof Kotowicz:
W najbliższą środę w Krakowie jest spotkanie wspomnianego już w tym wątku OWASPu dla developerów PHP, właśnie m.in. o SQL injection. Czytając wpisy w tym wątku przekonuję się, że ciągle jest kilka mitów na ten temat, więc zapraszam zainteresowanych - na pewno skorzystacie!
Więcej info tu:
https://lists.owasp.org/pipermail/owasp-poland/2010-Mar...
Jakub L. Programista
Darek Z.:
Np. podczas logowania podajesz login i hasło, gdzie obydwa to zlepki liter i liczb. Więc wystarczy usunąć wszelkie znaki poza zadeklarowanymi.
Stanisław P. Software designer
Darek Z.:Co ma piernik do wiatraka? Jak można przed obydwoma bronić się tym samym sposobem?
Jeśli chodzi o zabezpieczenie przed sql injection, to jest tego trochę, bo ja jednak wolę bardziej globalnie, czyli przy okazji zabezpieczania przed sql injection zabezpieczam np. przed XSS-em.
Zazwyczaj robię coś na bazie prepare, dodaje slesheCzyli nie dość, że prepare odpowiednio obrabia zapytania, to jeszcze dodajesz slashe które są zapisywane jako slashe w bazie?
a tam gdzie nie trzeba usuwam wszelkie tagi i znaczki których nie powinno być.Czyli jak chcę mieć bezpieczne hasło "(%@'jr!$@!&!';" to ktoś będzie się mógł zalogować wpisując "jr"? I nie mogę w Twoich aplikacjach pisać przykładów w html'u, bo zamiast poprawnie je wyświetlić, wytniesz je zupełnie? Tak samo jak "2<3 ale 3>2" zmieni się w "22"?
Np. podczas logowania podajesz login i hasło, gdzie obydwa to zlepki liter i liczb. Więc wystarczy usunąć wszelkie znaki poza zadeklarowanymi.
konto usunięte
Jakub L.:
I w tej sytuacji hasło 123abc123 jest takie samo jak 123$%^a&b*c(1@23# ?
konto usunięte
Michał
Jastrzębski
Django-fu, phpjutsu,
sql-do
Stanisław P. Software designer
Michał Jastrzębski:Wszystko co potrzeba jest już dostępne: jeśli piszesz do bazy masz prepared queries, jeśli piszesz do usera masz html escaping. Czemu chcesz dodawać własny potencjalnie zbugowany kod zamiast sprawdzonych oficjalnych metod, które przeszły test czasu?
Mam taki pomysł, aczkolwiek nie wiem czy dobry. Dlaczego nie zamienić wszystkich znaków specjalnych na reprezentację unicode? Np. " na \&\#34;. Można napisać prostą klasę przerabiającą znaki specjalne na unicode i odwrotnie.Michał Jastrzębski edytował(a) ten post dnia 05.03.10 o godzinie 12:55
Michał
Jarosz
Frontend Developer &
Team Leader
konto usunięte
Wojciech
K.
realizator pomysłów
własnych
Piotr Likus:
addslashes() should be deprecated - it does not protect against
SQL injections
Następna dyskusja:
пропозиції роботи
