Home > Uncategorized > Jakie pytania na konkursach?

Jakie pytania na konkursach?

Na konferencjach programistów bywają konkursy. Pytania na tych konkursach bywają przykre. Postanowiłem więc zacząć zbierać listę zagadnień, które mogą być tematami konkursów dla deweloperów, które nie będą przykre i które będą uczyć czegoś studentów obecnych często na konferencjach. Nie będę się wysilał i wymyślał takich zagadnień specjalnie. Jednak gdy coś mi się trafi, to o tym napiszę. Tak jak dziś.

Zadanie: wskaż ryzyko związane z tym kodem.

Categories: Uncategorized Tags:
  1. August 1st, 2009 at 08:26 | #1

    A czy taki trick przejdzie? http%73://example.com – %73 to ‘s’ w hex-ascii. Rozwiązaniem byłoby utworzenie instancji klasy URL (w Javie), a tam jest chyba odpowiednia metoda do zwrócenia schematu http/https (?)

  2. August 1st, 2009 at 09:14 | #2

    @Tomek Nurkiewicz nie próbowałem – tak na oko to raczej nie przejdzie. Jeżeli podasz jako parametr URL “%73″ to w PHP będziesz miał “s” i dalsze polecenia się wykonają, jednak – nic to nie da atakującemu.
    Znane mi zagrożenia:
    1. Kod działa jako anonimowe proxy, haker może ukryć się za naszym serwerem i napaś na inne serwery w Internecie.
    2. Mogą to być wrota to ataku na nasz system, na przykład można pobrać zasoby lokalne, do których dostęp normalnie byłby zabroniony, np.: http://localhost/ lub http://localhost:8080/manager/ i w ten sposób odkryć niedoróbki w konfiguracji.
    3. Można zapętlić serwer.
    Kto da więcej?

  3. August 3rd, 2009 at 08:18 | #3

    Ja ogólnie bym te $_GET['url'] ładnie przefiltrował, jeśli już musi być w postaci domeny ze wskazaniem na plik, a nie tylko wskazanie na maszynie…

  4. blackfire
    August 3rd, 2009 at 21:21 | #4

    4. Można zDoSować serwer każąc mu zassać dowolny duży plik — w $contents się obraz typowego DVD raczej nie zmieści.

    5. Ponieważ serwujemy dowolny content wskazany przez napastnika, to XSS chyba podpada pod kopanie leżącego, nie? :)

    ad. 3. Jakim requestem? Bo na chłopski rozum powinno się dać, ale nie widzę wartości parametru URL, dla którego całość się zapętli. Przy wywołaniu http://foo/?url=http://foo/ strona zostanie pobrana dwa razy, raz z parametrem, a raz bez, więc to takie średnie zapętlenie.

  5. August 11th, 2009 at 08:40 | #5

    @blackfire ad 3. racja. Zapętlić tak się nie da…

  6. August 11th, 2009 at 08:57 | #6

    Mój krótki przykład miał ilustrować mechanizm często wykorzystywany w serwisach www. Użytkownik podaje jakiś adres. Nasz serwer wczytuje ten adres URL, przetwarza go (czego nie było w tym przykładzie) i kiedyś później prezentuje wyniki… Zadanie jest niby proste. Ale jak wykonać je bezpiecznie?

    @blackfire ad3. zapętlić da się przez XSS. Ale to już jest takie brzydkie…

  7. August 11th, 2009 at 09:20 | #7

    @matipl filtrowanie tego jest skomplikowane. Pierwsze co przychodzi mi do głowy to wybranie domeny z adresu URL. Następnie należało by sprawdzić, czy nie jest to domena lokalna lub w sieci wewnętrznej.: 127.*, 10.*, 192.*. Natomiast, to nie wyklucza zagrożeń związanych z proxy… Aby zabezpieczyć nasz serwer, by nie mógł służyć do atakowania proxy, należało by wprowadzić limit żądań z jednego adresu IP w określonym czasie…

    Tak na prawdę, ten skrypt ma dwa różne problemy.
    Pierwszy pobieranie URL.
    Druki wyświetlanie URL. W prawdziwym życiu zanim coś wyświetlimy zwykle następuje przetwarzanie…

    Dobra, my tu sobie bla, bla, bla o teorii. A jaka jest praktyka?
    http://www.google.pl/search?q=flex+cross+domain+proxy+php

    Jak myślicie, na ilu tysiącach serwerów zainstalowany będzie taki skrypt?

  1. No trackbacks yet.

Subscribe without commenting