Trzeba byś sierotą by nie stosować htmlspecialchars() przy wyświetlaniu jakichkolwiek danych pochodzących od użytkownika.
Poza tym nie tylko formularze są podatne. Również można preparować linki odpowiednio. Tylko co za baran dopuszcza do wyświetlenia link bez obcięcia z niego java_script: ??

A wystarcza jedno kliknięcie w odpowiednio spreparowany link by wysłać ciasteczka z danej witryny na jakąś stronę która je zapisze do pliku/bazy danych. A przy niektórych popularnych skryptach od razu przeprowadzi z ich użyciem proces autologowania (bo na ogół Ci którzy proces autologowania mają oparty tylko na ciasteczkach sobie szkodzą) i zmiany hasła.

No ale tak to jest jak ludzie chcą autorski CMS z super rzeczami za 500-1000zł. Później płaczą bo ten CMS jest tak dziurawy że byle dzieci potrafią go załatwić. Przynajmniej potem tacy ludzie płacą tyle samo albo i więcej co za serwis żeby ktoś go połatał. Pamiętajcie że jak ktoś umieści na stronie słowo "profesjonalnie" to nie zawsze oznacza że jest profesjonalistą.

Trzeba być sierotą by korzystać z PHP. Teraz takie pytanie. Załóżmy, że znalazłem błąd XSS na jakiejś stronie. Zgłaszam administracji strony, ale ta mnie olewa.
Ad1. czy jeżeli opublikuję tę lukę, to czy coś mi grozi? Czy firma może stwierdzić, że było to dla nich ze szkodą?
Ad2. Co powinienem w takim przypadku zrobić?
Ad3. Czy użytkowników również chroni jakieś prawo nakładające obowiązek zabezpieczania serwisu/systemu informatycznego i reagowanie na zawiadomienia o niebezpieczeństwach?

Zgłaszasz im to a tu za chwilę policja puka i pyta dlaczego szukałeś luk w tej witrynie :P

Co do pk3 to sprawa jest dwojaka. Był kiedyś tu na di artykuł o chłopaku który zgłosił lukę najpierw firmie (która nie zareagowała) a potem dopiero jej klientom (którzy zgłosili to do firmy, ta wezwała chłopaka do siebie gdzie już czekała policja). Chodziło o SQL Injection... w formularzu logowania :-D
Chłopak został uniewinniony gdyż wg prawa nie złamał żadnych zabezpieczeń. Dlaczego ? Bo ich nie było.

Najlepiej informację o luce zachować dla siebie i mieć święty spokój. Niech się serwis martwi bo prawo Cie nie broni. Ewentualnie puść gdzieś w obieg informację o niej, ktoś się zabawi kosztem serwisu a ten się o luce dowie.

PS: Skoro trzeba być sierotą by korzystać z PHP to może oświecisz sierotki ? :P

Trzeba być sierotą, żeby myśleć, że jakaś konkretna technologia da nam stuprocentowe bezpieczeństwo. Porządnie napisany system jest bezpieczny na ataki. To, że większość 'programistów' PHP myśli, że jak 'umią' zrobić pętlę to wystarczy aby pisać złożone systemy informatyczne - to nie jest to wina technologii, tylko firm które w pogoni za zyskiem zatrudniają coraz mniej doświadczonych ludzi (ten już za dużo umie - będzie chciał podwyżkę - wymieńmy go na studenta).

Z tym PHP to pewnie jest tak jak z Windowsem. Trzeba być sierotą by z niego korzystać... (powiedział mega-wypasiony-linux-user, który reinstaluje linuxa, jak tylko tryb graficzny się nie chce odpalić...)

Podstawa to filtrowanie wszystkich danych pochodzących od użyszkodnika.

Ja proponuje przestac skupiac sie na kwestiach technicznych na chwile a popatrzec na kwestie prawne:

"W pierwszej kolejności należy zwrócić uwagę na regułę wyrażoną w art. 415 Kodeksu cywilnego, który normuje zasadę odpowiedzialności opartej na winie sprawcy szkody. Za szkodę odpowiada osoba, której zawinione zachowanie jest źródłem powstania tej szkody. Zdarzeniem sprawczym będzie tutaj zarówno działanie, jak również w pewnych przypadkach zaniechanie."

Szczegolnie interesujace jest ostatnie zdanie bo jak dla mnie wynika z niego jasno, ze zaniedbanie zwiazane z brakiem filtrowania wejscia od klienta bedzie wystarczajace aby uznac wykonawce serwisu za winnego. Do tego analogiczna sytuacja z SQL Injection - brak zabezpieczen oznacza brak mozliwosci ich przelamania a wiec uniewinnienie osoby atakujacej.

Problemem jest generalnie szara strefa, w ktorej mamy sytuacje, ze "jakies" zabezpieczenia sa ale sa niewystarczajace. Czy doszlo do ich przelamania?

Co z przypadkiem gdy zabezpieczenia byly zaprojektowane (nawet bardzo dobrze zaprojektowane) ale zle (lub w ogole nie) zaimplementowane? W takim przypadku dla mnie jest jasne kto jest winny - wykonawca serwisu. Czy Sad zgodzi sie z taka interpretacja?

Każdy kto zbiera dane osobowe powinien o nie dbać, "znać się" na zabezpieczeniach, skanować serwer, śledzić nowe luki.
Jeżeli ktoś tego nie potrafi nie nadaje się do tego typu pracy i powinien zostać ukarany jeżeli dane wypłyną.
Jest cała masa "adminów" po kursach microsoftu, do ich stron i serwerów nie trzeba używać mózgu, wystarczy metasploit/stary core impact i jakiś skaner luk xss/sql.
Durny automat potrafi "wbić się" na większosć tego typu stron.

Cardill, masz racje ale chodzi tu o coś innego.
Windows uczy niezagłebiania się, odpycha usera przy jakiejkolwiek próbie wychylenia sie poza schemat, ludzie uczą się programować w ten sposób i np. zabezpieczają przed sqlinj pole loginu ale wyszukiwarke zostawiaja w spokoju (bo przecież nikt nie zapuści sql injection w wyszukiwarce...).
Luki najlepiej sprzedać, zachować na później, albo skompromitować zabezpieczenia np. udostępniając na stronie głównej baze userów z wymazanymi hashami i adresami email.
Następnym razem koleś będzie wiedział, że książka "PHP dla opornych - edycja uproszczona" to nie wszystko.
Jeżeli po ataku i wysłaniu informacji o luce do admina nic z tym nie zrobi powinien być ścigany za niedopełnienie obowiązków.

„Tylko co za baran dopuszcza do wyświetlenia link bez obcięcia z niego java_script: ??”

Źle. Powinna być whitelista dopuszczonych schematów, a nie odwrotnie. :)

Proponuje blizaej zapoznac sie z wynikami skpraw jakie mialy miejsce juz w Polsce, a ktore odnosza sie np. do wykrycia SQL Injection. Nie jest tutaj zlamane zabezpieczenie, poniewaz takowe nie istanieje.
DI chyba znow pisze o czyms o czym nie ma pojecia (https://di.com.pl/news/23837,1,0,Precedensowy_wyrok_w_sprawie_SQL_Injection.html)

mcv, kwestia projektu :P Swoją drogą najbardziej mi się podobała akcja z jedną witryną w której pracowali na prawdę "programiści artyści".
Napisali oni bardzo ładny moduł który prowadził statystykę dotyczącą przeglądarki i systemów operacyjnych. Następnie robili wpis w bazie danych no i wszyscy zadowoleni.

Pracowało podobno przy tym 2 osoby (tak mi powiedział klient który zlecił mi później poprawienie całej witryny po tym jak pokazałem mu 3 miejsca które pozwalają na cuda z jego witryną co pokazałem mu na jej dokładnej kopii) i żadnemu do głowy nie przyszło że... nagłówki nie tylko przeglądarka wysyła :P
Odpowiednio spreparowany nagłówek i można było robić co się chciało.

Ludzie. WSZYSTKO co pochodzi z zewnątrz - jeżeli to wykorzystujemy (a czasami nawet kiedy nie) stanowi zagrożenie.
Pracodawcy. Za 1200zł nikt normalny nie przyjdzie wam do firmy pracować. A jak przyjdzie to potem macie takie kwiatki jak tutaj napisałem. Przyzwoity programista sam w domu zarobi znacznie więcej. A do pracy podobno idzie się by polepszyć swoje warunki a nie je pogorszyć.

A później jeden z drugim będzie się tłumaczył, że nie wiedział o odpowiedzialności. Za fraki ich! ;-)

Gostek, kiedy wreszcie skonczysz ze SPAMEM???

Jak się nie filtruje zmiennych oraz innych danych pochodzących z zewnątrz to takie sytuacje występują :)

Ja wychodzę z takiego założenia, że stronę www można porównać z płotem koło domu. Skoro "ledwo stoi" to ktoś obcy ma w niego kopnąć, żeby się rozleciał? Czy lepiej, żeby napisał tekst na płocie "popraw płot"? Czy lepiej jak powie właścicielowi, że płot ledwo stoi?
Moim zdaniem informowanie właścicieli stron nie o lukach na nich nie powinno być żadnym przestempstem jeżeli nie doprowadza to do wyłudzeń lub zszargania opinii kogoś.

Jak ja uczyłem się PHP to pare ładnych lat temu. Poznawałem wszystko z poradników i z Internetu, fora itd. Dopiero po przeczytaniu paru podręczników + informacje na forach dają możliwości do pisania "w miarę" dobrych stron. Wiadomo, że zawsze mogą trafić się ludzie, którzy dane zabezpieczenie są w stanie obejść to, że ogrodzimy dom płotem nie gwarantuje nam bezpieczeństwa w 100%.

Poza tym poważne aplikacje wymagają BARDZO DUŻO wiedzy. Bazy danych, php, postgresql, css, html, Ajax (coraz bardziej modny), administracja linuksem i sieciami oraz wiele innych. To, że ktoś zna trochę tego i tego nie gwarantuje napisanie dobrej aplikacji. Skomplikowane bazy danych zawierają dziesiątki a nawet setki tabel powiązanych relacjami ze sobą. Wystarczy wgłębić się w temat i wtedy widać "jak dużo drzew jest"...