Sposoby zabezpieczania aplikacji przed atakiem SQL INJECTION

0

Witam!
Bardzo prosił bym o podanie wszystkich znanych wam sposób zabezpieczania swoich aplikacji przed atakiem SQL INJECTION.

Piszę sobie własnie aplikacje bazodanową w Windows Forms i ADO .NET i zabezpieczyłem ją przy użyciu parametrów.

Mam funkcję która sprawdza czy w textboxie nie znajdują się znaki tj np ' , - czy = i działa fajnie :)

Na jakie inne sposoby można to jeszcze zabezpieczyć?
Z góry dzięki :)

0

To jest najgorszy możliwy sposób "obrony" (o ile w ogóle można go do takich sposobów zaliczyć). Jeśli już chcesz robić listę to rób whitelistę a nie blacklistę, czyli przypuszczaj tylko określony zestaw symboli.
Poza tym proponuje używać takich rzeczy jak prepared statements a nie gołych sklejanych stringów do wysyłania zapytań do bazy, albo uzywać jakichś DSLi do tego.

0

No spoko :)

A wyjaśnił byś na czym polegają te Twoje niby lepsze sposoby?

0

Tyle to też potrafie sobie znaleźć w google...

Chodzi mi o jakieś wyjaśnienie po ludzku....

1

W prepared statement nie trzeba się bawić w filtrowanie znaków, bo zajmuje się tym (z reguły) sterownik. Ewentualnie przy prepared statementach filtrowanie może być w ogóle niepotrzebne, gdyż sterownik może używać oddzielnego formatu zapytań. Oprócz tego gratis może jeszcze być np typowanie czy zwiększona wydajność gdy używa się jednego prepared statement wielokrotnie (zależy od sterownika).

Jest o tym zresztą w przytoczonym artykule na Wikipedii:

As compared to executing SQL statements directly, prepared statements offer two main advantages:[1]
The overhead of compiling and optimizing the statement is incurred only once, although the statement is executed multiple times. Not all optimization can be performed at the time the prepared statement is compiled, for two reasons: the best plan may depend on the specific values of the parameters, and the best plan may change as tables and indexes change over time.[2]
Prepared statements are resilient against SQL injection, because parameter values, which are transmitted later using a different protocol, need not be correctly escaped. If the original statement template is not derived from external input, SQL injection cannot occur.
(...)
A number of programming languages support prepared statements in their standard libraries and will emulate them on the client side even if the underlying DBMS does not support them, including Java's JDBC,[12] Perl's DBI,[13] and PHP's PDO.[1] Client-side emulation can be faster for queries which are executed only once, by reducing the number of round trips to the server, but is usually slower for queries executed many times. It resists SQL injection attacks equally effectively.[1]

Mam przeklejać Wikipedię czy co?

0

W asp.net web forms najprościej wykorzystać session do przekazywania zmiennych między formami. Dawno nie spotkałem programu, który przekazywałby query jawnie w adresie URL. Tak więc wymyślanie tego typu zabezpieczeń to robota bezsensu

0

W tym temacie nie ma mowy o web aplications tylko zwykłym Windows Forms wiec o jakim URL mówisz?

Ok :)
A istnieje jeszcze coś oprócz prepered statments?:)

0

parametry

0

To juz znam i tak właśnie zrobiłem :) Inne pomysły?

0

faktycznie - pomyliłem się

1 użytkowników online, w tym zalogowanych: 0, gości: 1