9:25
11/3/2010

Oto prezentacja, jaką Krzysztof Kotowicz wygłosił na wczorajszym spotkaniu OWASP-u:

Inne zmagania Krzyśka z webaplikacjami możecie śledzić na jego blogu.


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

14 komentarzy

Dodaj komentarz
  1. Przydatne. Dziękować :-).

  2. Genialne i kompletne merytorycznie podsumowanie całego problemu, szkoda, że nie mogłem tego oglądać na żywo, bo na pewno autor miał sporo do dodania od siebie.

  3. To ja od siebie dodam ciekawostkę jedną w temacie blind sqli i obchodzenia różnych filtrów:

    http://blog.didierstevens.com/2010/02/02/quickpost-quasi-tautologies-sql-injection/

    Bardzo mi się podobają te “prawie tautologie” :)

  4. Muszę przyznać, że prezentacja została przygotowana bardzo estetycznie. Na pewno przyda się jakiejś grupie osób, niemniej jednak najlepszym narzędziem do obrony przed atakami typu SQLI jest sam programista.

  5. jak dla mnie zabraklo informacji o takim zapisie
    mysql: SELECT `id`, `name` FROM `some_table`;
    pgsql: SELECT “id”, “name” FROM “some_table”;
    przy escape’owaniu obiektow, co prawda nie zapobiega to wysypaniu sie zapytania w przypadku wstrzykniecia informacji ale pozwala je wykryc

  6. Sam programista to jest zwykle POWODEM podatności na SQLi. Im mniej ma okazji na popełnienie błędu, tym lepiej. I o tym między innymi w tej prezentacji jest mowa.

  7. @Krzysztof Kotlarski

    A to z tej przyczyny, ze nie zaleca sie escape’owania nazw obiektow jako metody zabezpieczenia sie przez SQLi (to jest po prostu dziurawe). Przeczytaj np. tu: http://www.owasp.org/index.php/Guide_to_SQL_Injection#WARNING:_Escaping_table_names
    Omawiane frameworki maja zwykle metody quoteIdentifier(), ktora raz dziala w miare dobrze, raz tragicznie zle (wycialem to z prezentacji ze wzgledow czasowych).

    Ale zawsze, jesli parametry z inputa dokleisz do SQLa jako nazwy obiektow (niewazne, czy escape’owane), to az sie prosi o wysypanie zapytania podajac np. nieistniejaca tabelke/kolumne. A wysypanie zapytania to juz jest ZUO.

  8. Prawdopodobnie już w przyszłym tygodniu umieścimy webcasty zmontowane z materiału jaki udało się nagrać podczas spotkania. Szczegóły w pierwszej kolejności pojawią się na liście owasp-poland (http://www.owasp.org/index.php/Polandhttp://lists.owasp.org/mailman/listinfo/owasp-poland)

  9. @Krzysztof Kotowicz
    Wydawalo mi sie troche dziwne ze wspomniales o addslashes() a o tym nie. Osobiscie nie zdazylo mi sie jeszcze kierowac bezposrednio tresci z inputa gdziekolwiek przed where w (pod)zapytaniu ale nie powstrzymuje sie przed wykorzystywaniem zmiennych wewnetrznych do tego celu. Przy wiekszych ilosciach kodu i TDD latwiej w ten sposob utrzymac pozadek niz za pomoca bialych list no i eliminuje ryzyko zbieznosci nazw ze slowami kluczowymi.
    Maly brak ale sama prezentacje odbieram calkiem pozytywnie;)

  10. @Krzysztof Kotlarski

    Jeśli zmienne, które będą nazwami obiektów pochodzą od Ciebie (programisty) – ok, możesz je escape’ować wg zasad używanej bazy. Ale wtedy to już raczej kwestia składni SQL niż stricte tematu SQL injection, dlatego (+ względy czasowe) nie dałem tego w prezentacji.

    Co do addslashes() – też myślałem, że nikt tego od lat nie używa. Ale w codziennej praktyce przekonuję się, że niestety jestem w błędzie. Nawet polska wikipedia http://pl.wikipedia.org/wiki/SQL_injection promuje moją ulubioną funkcję.

    Dzięki za rzeczowe uwagi!

  11. Znowu php z adhd… czy ktoś może przygotować taki materiał o np. JPA. Chętnie zobaczę, że w Javie się też da.

    Sama prezentacja bardzo fajna i rzeczowa. Kilka elementów trafiło na moją prywatną listę pytań do starających się o stanowisko programisty php z adhd.

  12. […] OWASP, gdzie prezentował techniki tworzenia i analizy malware’u w Javascript oraz metody zabezpieczenia przed SQL injection. Zaproponował również bezpieczną metodę podpisywania kodu w […]

  13. […] OWASP, gdzie prezentował techniki tworzenia i analizy malware’u w Javascript oraz metody zabezpieczenia przed SQL injection. Zaproponował również bezpieczną metodę podpisywania kodu w […]

  14. […] OWASP, gdzie prezentował techniki tworzenia i analizy malware’u w Javascript oraz metody zabezpieczenia przed SQL injection. Zaproponował również bezpieczną metodę podpisywania kodu w PHP, a niedawno pokazał ataki na […]

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: