javascript w obrazku Opcje

[sazian]

Witam,
ostatnio puściłem skan w poszukiwaniu frazy document.write i ku mojemu zdziwieniu znalazło to w pliku gif (IMG:style_emoticons/default/smile.gif)
dokładniej wygląda to tak - jest to doklejone na końcu obrazka

[HTML] pobierz, plaintext 
<script type="text/javascript"><!--
document.writeln('<'+'scr'+'ipt type="text/javascript" src="tu adres do jakiejś strony"></'+'scr'+'ipt>');
//--></script>
[HTML] pobierz, plaintext 

zacząłem z tym trochę kombinować i owszem da się dopisać dowolny kod bez uszkadzania pliku ale nie daje się on uruchomić.
Jakie warunki trzeba spełnić aby taki kod został uruchomiony (IMG:style_emoticons/default/questionmark.gif) czy daje się on w ogóle uruchomić (IMG:style_emoticons/default/questionmark.gif)

[thek]

Daje się... Jest to "test" przetwarzania obrazów i zabezpieczeń serwera. Ogólnie... Problem w tym, że niektórzy do serwowania obrazów używają funkcji z rodziny include czy require. To odpali z reguły kod (IMG:style_emoticons/default/wink.gif) Możesz ogólnie o obrazach poczytać tutaj. http://darksidegeeks.com/complete-file-upl...ulnerabilities/ Zwłaszcza zainteresuje Cię fragment: "Image File Content Verification"

[sazian]

ok tylko z tego co tak na szybko przejrzałem to tam chodzi o wstawienie pliku php zamiast obrazka i późniejsze uruchamianie tego skryptu

a w moim przypadku jest to kod js doklejony do normalnego obrazka, mogę go normalnie wyświetlić w przeglądarce czy otworzyć gimpem
czyli autor zapewne przewidywał że będzie się dało to uruchomić
jeśli go wczytuję przez <img src /> kod js nie jest uruchamiany

ps. a tak swoją drogą to chyba bym nie wpadł na pomysł że obrazek można include pociągnąć (IMG:style_emoticons/default/biggrin.gif)

[nospor]

Obrazki/zasoby/pliki można zwracać nie bezpośrednio przez ścięzkę do nich, ale np. przez skrypt php.
Np. gdy chcesz wpierw sprawdzac czy ktos moze miec dostep do tego, albo gdy zwracasz dynamicznie obrazki, albo gdy chcesz ukryć ściężkę do obrazka.

Wówczas skrypt php ma np. taki kod:

//tu jakieś nagłówki
//header
readfile('obrazek.png');

w takim wypadku skrypt js prawdopodobnie się wykona.

[sazian]

no niestety nie
próbowałem z file_get_contents i readfile
nic
dokleiłem kod php i też nic
dopiero kod php + include zadziałało

ale to i tak nie zmienia faktu że js nie daje się uruchomić

[ano]

Czemu niby skrypt JS miałby się wykonać? Jeżeli nagłówki odpowiedzi są poprawne (mimetype odpowiedzi oznaczony na obrazek) to przeglądarka nie bedzie próbowała interpretować odpowiedzi jako html - nic sie nie "odpali". Nie ważne czy include, czy file_get....

Myślę, że mylicie to z atakiem polegającym na użyciu spreparowanego obrazka - z kodem PHP. Wtedy przy include móglby się odaplić zaszyty kod.

[sazian]

ok tylko poco ktoś by dodawał taki kod skoro i tak nigdy się nie uruchomi

[Pawel_W]

może ktoś chciał Ci zawirusować serwer i zamiast dodać ten kod tylko do plików .html i .php przez przypadek ((IMG:style_emoticons/default/questionmark.gif) ) dodał do wszystkiego co było (IMG:style_emoticons/default/smile.gif)

[Pilsener]

Żeby sprawdzić mechanizmy bezpieczeństwa choćby. Kiedyś polecany i popularny był sposób, by wczytać kilka pierwszych i ostatnich bajtów pliku. Dziś już nie trzeba tego robić bo są dedykowane maszyny tylko pod obrazki i specjalne biblioteki do sprawdzania plików, zwłaszcza obrazków. Byle lamer nie złamie. Poza tym nigdy nie mów nigdy, w tym wypadku akurat się nie wykona ale może ktoś chce to połączyć np. z awarią serwera? To tak jak kod PHP teoretycznie nigdy nie powinien być widoczny na stronie a w praktyce wiele razy już to widziałem.

[nospor]

Czemu niby skrypt JS miałby się wykonać? Jeżeli nagłówki odpowiedzi są poprawne (mimetype odpowiedzi oznaczony na obrazek) to przeglądarka nie bedzie próbowała interpretować odpowiedzi jako html - nic sie nie "odpali".

1) Czasami przeglądarka zamiast wyświetlać zdjęcie, wyświetla jego zawartosc - i ups, js się wykona. Bug przeglądarki?
2) Czasem ktoś stworzy złe nagłówki i ups, kod js się wykona.

[ano]

1) Czasami przeglądarka zamiast wyświetlać zdjęcie, wyświetla jego zawartosc - i ups, js się wykona. Bug przeglądarki?
2) Czasem ktoś stworzy złe nagłówki i ups, kod js się wykona.

1 - ? Podaj przykład? Jakby to przeglądarka się wywaliła to przecież kodzik js nie ma prawa się wtedy odpalić... (Bo się wywaliła przeglądarka (IMG:style_emoticons/default/wink.gif) )
2 - czasem ktoś wyłączy interpreter php i ups kod php się pokaże... - sorry, ale to taki sam argument ;p

Zainteresowanym min. tym tematem polecam książke lcamtufa "The tangled web" (http://lcamtuf.coredump.cx/tangled/).
Część jednego rozdziału jest poświęcona dokładnie temu zagadnieniu wraz z radami jak się uchronić.

Trzeba pamiętać, że sama przeglądarka zapewnia pewny stopień bezpieczeństwa (najprostszy przykład - same origin policy, zabezpieczenia przed osadzeniem strony w ramce przez odpowiednie nagłówki odpowiedzi itp)

Ciekawostka: bodajże od wersji 8 InternetExplorer posiada zabezpieczenia przed atakami XSS :DDD

[nospor]

1) A czy ja powiedziałem ze się wywala? Czasami poprostu wariuje i wyświetla kod obrazka, zamiast go odpalić
2) Nie, bo jak ktoś schrzani nagłówki, a obrazki będą dobre, to nic się nie stanie. Ale jak ktoś podrzuci lewy obrazek, a nagłówki będą schrzanione, to właśnie się stanie kuku.

Pytanie w tym wątku było: po co dawać js w obrazku?
Odpowiedz już padła: po to, ze jak ktoś coś schrzani, to się kod wykona. Proste. Tyle w temacie.

Ciekawostka: bodajże od wersji 8 InternetExplorer posiada zabezpieczenia przed atakami XSS :DDD

Haha... jakieś szczegóły? Bardzo ciekawi mnie jak on rozpozna, że dany kod jest atakiem xss a nie celowym kodem autora aplikacji/redaktora serwisu?

[ano]

http://blogs.msdn.com/b/ieinternals/archiv...ttp-header.aspx

Podejrzyj np. odpowiedzi google.com ;p (http://stackoverflow.com/questions/9090577/what-is-the-http-header-x-xss-protection)

To trochę jak z magic quotes w php... (Kretynizm^2) ;P

Co ciekawe, przed chwilą sprawdzałem i Safari też ma analogiczne "zabezpieczenie" (IMG:style_emoticons/default/wink.gif)

Ten post edytował ano 15.02.2013, 00:22:08

[nospor]

Strach się bać, jak on już takie kody:

Kod

<script>alert("bang! script injection\n"+document.cookie);</script>

uznaje za XSS.
Znowy wrócą piękne czasy, gdy na stronie będzie pojawiał się komunikat:
Używasz IE8. Proszę zmień przeglądarkę na inną, gdyż z IE8 ta strona poprawnie działać nie będzie
lol

[pyro]

1) Czasami przeglądarka zamiast wyświetlać zdjęcie, wyświetla jego zawartosc - i ups, js się wykona. Bug przeglądarki?
2) Czasem ktoś stworzy złe nagłówki i ups, kod js się wykona.

1) @nospor, nawet jak przeglądarka wywali kod (tak, mi się też to zdarzyło), to kod się nie wykona, bo to na podstawie nagłówków przeglądarka decyduje z jakiego parsera ma korzystać. No chyba, że przeglądarka się zepsuje tak, że obrazki traktuje jako kod HTML, ale nie spotkałem się z czymś takim (IMG:style_emoticons/default/arrowheadsmiley.png)
2) No tak..., ale ktoś zapomni dać "<?php" albo ze zbyt szybkiego pisania "< ?php" i pokaże się cały kod PHP... oooppsss. Krzywda na własne życzenie i za własne niedbalstwo.

Ciekawostka: bodajże od wersji 8 InternetExplorer posiada zabezpieczenia przed atakami XSS :DDD

Te "zabezpieczenia", to tak naprawdę nie są żadne zabezpieczenia, tylko zwyczajne utrudnienia.

[nospor]

1) A mi się zdarzało i dośc czesto (IMG:style_emoticons/default/smile.gif)
2) Tak, tylko że jak komus pokaże się cały kod php, to przecież autor aplikacji to zobaczy od razu i od razu będzie mógł to skorygować. A jak coś spieprzy w nagówkach to może się okazać, że dopiero lewy obrazek to wykaże. A wówczas to nie autor aplikacji zobaczy błąd, a haker.

[pyro]

1) A mi się zdarzało i dośc czesto (IMG:style_emoticons/default/smile.gif)

Co? Zdarzyło Ci się, że przeglądarka wywaliła kod obrazka (z winy przeglądarki) i wykonał się w niej jakiś kod JS? Nie wierzę Ci (IMG:style_emoticons/default/snitch.gif)

[nospor]

Kod js się nie wykonywał, bo wówczas miałem normalne obrazki (IMG:style_emoticons/default/wink.gif) Dobra, niech będzie że punkt 1 został obalony. Ale zostaje punkt nr 2 jako odpowiedź na pytanie autora tematu (IMG:style_emoticons/default/smile.gif)

[pyro]

Kod js się nie wykonywał, bo wówczas miałem normalne obrazki (IMG:style_emoticons/default/wink.gif) Dobra, niech będzie że punkt 1 został obalony. Ale zostaje punkt nr 2 jako odpowiedź na pytanie autora tematu (IMG:style_emoticons/default/smile.gif)

Życzysz sobie, żebym obalił również i 2 punkt (IMG:style_emoticons/default/tongue.gif) ?

[nospor]

Dawaj. Chętnie zobaczę jak to zrobisz (IMG:style_emoticons/default/smile.gif)

[pyro]

Dawaj. Chętnie zobaczę jak to zrobisz (IMG:style_emoticons/default/smile.gif)

No to skoro część o tym, że równie dobrze można gdzieś indziej dać o jedną spację za dużo nie wystarcza, skupmy się na tym konkretnym przypadku - programista źle ustawił nagłówki dla obrazków.

1.) Trzeba być pijanym lub naćpanym, żeby pomylić np. image/png z text/html, ale załóżmy, że nagłówki są ustalane w sposób automatyczny, a autor np. pomylił index w tablicy z nagłówkami.
2.) Gdzie ktoś mógłby dodawać swoje obrazki? Profil użytkownika? Dodawanie nowego produktu do sklepu? Więc jak programista mógłby nie wypatrzeć tego błędu?
3.) W testach się sprawdza takie rzeczy. Programista, który nic nie testuje to żaden programista. Nie mówię już o takich rzeczach jak testy jednostkowe lub funkcjonalne, ale zwykłe chodzenie po portalu i patrzenie czy działa jak należy.
4.) Załóżmy, że wszystkie podpunkty wyżej padły (chociaż już jest to nieprawdopodobne). To teraz jaka jest szansa , że na stronę jako pierwszy jakiś haker co wykryje błąd, zanim wejdzie użytkownik i zgłosi błąd? 99% nie ma pojęcia o tego typu sprawach (IMG:style_emoticons/default/smile.gif) .
5.) Nawet jak wejdzie jako pierwszy haker, to na kim by miał używać tych ataków. No właśnie potrzebni są inni użytkownicy, a teraz patrz pkt. 4.

Czyli podsumowując: Żeby miała miejsce taka sytacja programista musiałby być pijany/naćpany, być slepy, nie testować w ogóle kodu, haker wejść przed innymi użytkownikami i dokonać ataku, zanim inni użytkownicy zgłoszą błąd. Czyli właściwie jaka jest na to szansa? 0,00000000000001 (IMG:style_emoticons/default/goatee.gif) ?

[nospor]

Powtarzam pytanie autora: po co ktoś wkłada js w obrazek, skoro on się nigdy nie wykona.
Odpowiedz: ponieważ istnieją sytuacje, kiedy jednak się wykona.

(IMG:style_emoticons/default/smile.gif)

[pyro]

No to jakiś przykład?

[nospor]

Przykład podałem: pijany programista dający złe nagłówki. Możliwe? Możliwe (IMG:style_emoticons/default/smile.gif)

[pyro]

Przykład podałem: pijany programista dający złe nagłówki. Możliwe? Możliwe (IMG:style_emoticons/default/smile.gif)

Możliwe, ale biorąc pod uwagę całą resztę (w tym moich postów) naciągane i to nie mało (IMG:style_emoticons/default/tongue.gif)

[nospor]

Ale możliwe. Odpowiedź na pytanie udzielona. Jakiś problem? (IMG:style_emoticons/default/tongue.gif)

[viking]

Z tego co pamiętam kod taki był w stanie się wykonać w konkretnych, starszych wersjach IE. Teraz raczej nie powinno do tego dojść.

[nospor]

był w stanie się wykonać w konkretnych, starszych wersjach IE

W starszych wersjach IE to wszystko było wstanie się wykonać (IMG:style_emoticons/default/wink.gif)

[Łukasz Piotr Łuc...]

Co po niektórych z tego wątku nie spodziewałbym się braku umiejętności korzystania z google ani braku ciekakowści (IMG:style_emoticons/default/smile.gif) Chyba panowie zbyt zramoraliście i spoczęliście na laurach (IMG:style_emoticons/default/wink.gif)

Przykładowy atak - jeden z wielu jakie możecie znaleźć z wykorzystaniem tej techniki:

1) wykorzystujemy dziurę w uploadzie plików graficznych i dodajemy javascriptowy comment payload do gifa test.gif
2) wykorzystujemy inny błąd (np. przy komentarzach, sql injection) i wstawiamy na stronę małe cuś: <script src="...../test.gif"></script>

Dzięki temu omijamy sprawdzanie origin i możemy dorwać się do ciasteczka. Jedynie pod IE jest to trochę utrudnione (ale nie niemożliwe).

W takim gifie można upakować więcej fajnych rzeczy. Jest także dostępna gifowa mixtura, która potrafi zrobić niezły bajzel (IMG:style_emoticons/default/smile.gif)

Ale więcej nie będę pisał by wannabe hakier nie kierować zwłaszcza, że niektórzy tworzą serwisy mówiąc że taka sytuacja nie jest możliwa więc nie zabezpieczamy się przed nią....

@pyro: akurat zmartwię Cię - nie musisz być naćpany ani pijany by zostawić dziurę w serwisie. Żaden test nie zapewni o bezbłędności ani nie wykryje wszystkich błędów. Istnieje kilka technik obrony przed spreparowanymi danymi uploadowanymi, ale to pozostawię Tobie jako pracę domową byś poszukał, poczytał, znalazł. A potem przyszedł i powiedział jak bardzo myliłeś się.

Pozdrawiam,
Łukasz

[nospor]

2) wykorzystujemy inny błąd (np. przy komentarzach, sql injection) i wstawiamy na stronę małe cuś: <script src="...../test.gif"></script>

Jak ktoś ma taką dziurę, że można mu wstawić własny kod js, to już naprawdę do niczego nie potrzebujemy zepsutego obrazka....

Próbowałem wykonać
<script src="...../test.gif"></script>
i niestety kod js zawarty w obrazku nie wykonał sie.
(no chyba ze zepsuty obrazek to tylko i wyłącznie js.... wowczas się wykona)

[Damonsson]

Specjalnie się zarejestrowałeś, żeby napisać, że jest możliwość wykorzystania tego, tylko wtedy gdy ktoś zrobi jeszcze głupsze błędy bezpieczeństwa w swojej aplikacji? Po co mam ładować kod do obrazka, jak mogę go wykonać i bez tego? Sztuka dla sztuki? A znowu nie wykonam go z samego obrazka, jeśli nie ma błędów umożliwiających wykonanie go i bez tego obrazka.

[Łukasz Piotr Łuc...]

nospor: nie doczytałeś stwierdzenia "Przykładowy atak - jeden z wielu jakie możecie znaleźć z wykorzystaniem tej techniki". Możesz mi uwierzyć na słowo, że się da albo nie wierzyć i dobrze poszukać informacji.


Damonsson: i cóż ja Ci mogę powiedzieć co? Nie pofatygowałeś się nawet by sprawdzić kiedy się zarejestrowałem. Więc pewnie tym bardziej nie pofatygowałeś się by sprawdzić czy w internecie nic piszą o takich atakach. Jakże więc mam próbować Cię do czegokolwiek przekonać skoro już masz z góry zakodowaną odpowiedź i niechęć do sprawdzania czy nie jest ona przypadkiem błędna.

[sazian]

dobra może podam trochę więcej szczegółów
ten obrazek został wgrany jako avatar ma forum postawionym na vbulletin, nie znam twórców tego skryptu ale wątpię żeby byli aż tak naćpani (IMG:style_emoticons/default/smile.gif)
Doklejony kod zawierał odwołania do serwera ze statystykami stron(stat.pl) a drugi do zagranicznego "sprzedawcy reklam"

co do pochodzenia tego kodu mam dwie teorie:
1)ktoś miał nadzieje że kod wykona się za każdym razem gdy na forum pojawi się jego avatar a on na tym zarobi (IMG:style_emoticons/default/smile.gif)
2)ktoś miał na komputerze wirusa który doklejał jakieś śmieci wszędzie gdzie się da

o ile kod wstawiony w <script src="test.gif"></script> rzeczywiście się wykonał to jednak nie widziałem aby ktokolwiek tak wstawiał obrazki

[pyro]

Co po niektórych z tego wątku nie spodziewałbym się braku umiejętności korzystania z google ani braku ciekakowści (IMG:style_emoticons/default/smile.gif) Chyba panowie zbyt zramoraliście i spoczęliście na laurach (IMG:style_emoticons/default/wink.gif)

Przykładowy atak - jeden z wielu jakie możecie znaleźć z wykorzystaniem tej techniki:

1) wykorzystujemy dziurę w uploadzie plików graficznych i dodajemy javascriptowy comment payload do gifa test.gif
2) wykorzystujemy inny błąd (np. przy komentarzach, sql injection) i wstawiamy na stronę małe cuś: <script src="...../test.gif"></script>

Dzięki temu omijamy sprawdzanie origin i możemy dorwać się do ciasteczka. Jedynie pod IE jest to trochę utrudnione (ale nie niemożliwe).

W takim gifie można upakować więcej fajnych rzeczy. Jest także dostępna gifowa mixtura, która potrafi zrobić niezły bajzel (IMG:style_emoticons/default/smile.gif)

Ale więcej nie będę pisał by wannabe hakier nie kierować zwłaszcza, że niektórzy tworzą serwisy mówiąc że taka sytuacja nie jest możliwa więc nie zabezpieczamy się przed nią....

Nagadałeś takich głupot, że aż drętwo się robi. W ogóle nie wiesz o czym jest temat, a postanowiłeś się wymądrzać chyba na podstawie słów kluczowych przelecianych oczami.

@pyro: akurat zmartwię Cię - nie musisz być naćpany ani pijany by zostawić dziurę w serwisie. Żaden test nie zapewni o bezbłędności ani nie wykryje wszystkich błędów. Istnieje kilka technik obrony przed spreparowanymi danymi uploadowanymi, ale to pozostawię Tobie jako pracę domową byś poszukał, poczytał, znalazł. A potem przyszedł i powiedział jak bardzo myliłeś się.

Praca domowa odrobiona. Nie umiesz czytać i w ogóle gadasz od tematu, to teraz praca domowa dla Ciebie: Pójdź gdzieś, gdzie nauczą Cię czytać (z tego co pamiętam robią to w podstawówce, ja ten etap mam już dawno za sobą), wróć, przeczytaj temat od początku ze wszystkimi postami i dopiero wtedy przyjdź i przyznaj jakie bzdury pleciesz.

[redeemer]

Widzę panowie, że zaczynacie się lekko "spinać". Pozwólcie więc, że wtrącę moje "8 groszy".

...
1) wykorzystujemy dziurę w uploadzie plików graficznych i dodajemy javascriptowy comment payload do gifa test.gif

Rozwijając słowa Łukasza "comment payload", to wcale nie trzeba doklejać złośliwego kodu "na koniec" pliku, ale np. w przypadku formatu GIF można dodać do pliku komentarz (wszystko zgodnie ze specyfikacją). Tak samo w przypadku JPEGów można spreparować dane EXIF, itd. (Gdyby ktoś był ciekawy gdzie fizycznie w pliku ląduje taki komentarz oto *hexdump* z gifa 1x1 i komentarzem w postaci skryptu js). Trzeba tutaj zaznaczyć, że o ile doklejenie "byle czego" na koniec pliku może powodować gubienie tych danych w przypadku obrabiania obrazków (lub nawet "błędy formatu" czy walidacji), to format takiego gifa z komentarzem jest w 100% poprawny. Dlatego też, nawiązując do samego wątku doklejanie czegokolwiek na koniec pliku jest dla mnie trochę dziwne i wygląda to właśnie na jakiś automat co infekuje wszystko co może bez analizy - czyli "dawaj na koniec". (drobna dygresja: większość binarnych formatów plików z którymi miałem coś więcej do czynienia, była/jest w formie "fixed-length", więc żadne dane nadmiarowe na końcu nie powinny ich zepsuć).

2) wykorzystujemy inny błąd (np. przy komentarzach, sql injection) i wstawiamy na stronę małe cuś: <script src="...../test.gif"></script>

Takie coś zadziała tylko pod warunkiem, że jak już napisał @nospor plik test.gif będzie tak naprawdę skryptem javascript o zmienionym rozszerzeniu na gif. Wątek natomiast tyczy się kodu javascript wplecionego w obrazek (pal licho czy "na końcu", czy "w środku" wykorzystując właściwości formatu pliku) i biorąc to pod uwagę to wykonanie tego kodu graniczy z cudem, bo przeglądarka (pomijając IE6 i inne eksponaty z muzeum) próbując sparsować taki plik zwyczajnie napotka "syntax error" i przestanie parsować ten skrypt (Chrome:"Unexpected token ILLEGAL", Firefox:"SyntaxError: illegal character", IE: "SCRIPT1014: Nieprawidłowy znak"). Zresztą gdyby to zadziałało, to każdy serwis przyjmujący obrazki od użytkowników i nie usuwający z automatu takich rzeczy z przesyłanych plików, mógłby "hostować" jakieś dziwne kody javascript.

...
Dzięki temu omijamy sprawdzanie origin i możemy dorwać się do ciasteczka. Jedynie pod IE jest to trochę utrudnione (ale nie niemożliwe).

To śmiało możesz doprecyzować bo wydawało mi się że same origin policy czy CORS nie dotyczy tagu <script>? [(IMG:style_emoticons/default/smile.gif) ]

[sazian]

Takie coś zadziała tylko pod warunkiem, że jak już napisał @nospor plik test.gif będzie tak naprawdę skryptem javascript o zmienionym rozszerzeniu na gif. Wątek natomiast tyczy się kodu javascript wplecionego w obrazek (pal licho czy "na końcu", czy "w środku" wykorzystując właściwości formatu pliku) i biorąc to pod uwagę to wykonanie tego kodu graniczy z cudem

no tak nie do końca
zrobiłem takiego potworka <script src="test.gif"></script> gdzie test.gif jest prawidłowym obrazkiem z doklejonym kodem i częściowo zadziałało.
Do testów użyłem dwóch kodów js
-pierwszy dodaje ciasteczko - i ten zadziałał
-drugi wywołuje funkcje alert - a ten już nie działa

więc o ile samo uruchomienie w ten sposób jest możliwe to już wystąpienie takiej sytuacji jest bardzo mało prawdopodobne

[redeemer]

no tak nie do końca
zrobiłem takiego potworka <script src="test.gif"></script> gdzie test.gif jest prawidłowym obrazkiem z doklejonym kodem i częściowo zadziałało.
Do testów użyłem dwóch kodów js
-pierwszy dodaje ciasteczko - i ten zadziałał
-drugi wywołuje funkcje alert - a ten już nie działa

więc o ile samo uruchomienie w ten sposób jest możliwe to już wystąpienie takiej sytuacji jest bardzo mało prawdopodobne

Jesteś pewien, że nie miałeś wcześniej tego ciastka? Jakiej przeglądarki użyłeś? Wystaw ten test.gif, bo nie chce mi się wierzyć (IMG:style_emoticons/default/wink.gif)

[sazian]

(IMG:style_emoticons/default/facepalmxd.gif)
wróć
mój błąd
tyle już z tym plikiem kombinowałem że zapomniałem do doklejonym kodzie php
a do tego przechodził przez plik
header('Content-Type: image/gif');
include ('test.gif');

Einstein miał racje, głupota ludzka granic nie zna