Skocz do zawartości

atsuki

Użytkownicy
 Wyświetl profil  Zobacz jego aktywność

  • Zawartość

    58

  • Rejestracja

  • Ostatnio

Posty napisane przez atsuki

  3. Napisano · Raportuj odpowiedź

    Nie łapie plików tylko łapie requesty URI. A tu, jak widać to request URI wcale nie jest tożsamy z plikiem.

     

    Mea culpa, o to mi chodziło ;)

     

    Druga sprawa - przy takiej strukturze, jaką opisał jednoliterowiec p, to wtedy można ustawić parser PHP tylko dla kontekstu 

    ^/scripts/(.*)\.php$

    , a nie dla całego docroota.

     

    Można, można też dodać to co napisał na liście autor nginxa

     

    location ~ \..*/.*\.php$ { 
return 403; 
}

     

    jak i wiele innych rzeczy... sprawdzanie uploadowanego pliku czy jpeg to jpeg etc. Ale np. Przy wordpressie nie ma żadnego problemu z uploadem pliku i jego wykonaniu.

     

    @p

    Aha. Ale to nie zmienia jednego podstawowego faktu. ile skryptów - for, blogow, cms ma układ katalogów w taki opisany przez ciebie sposób? Ile osób korzystających z nginxa ma skonfigurowane php w inny sposób niż ten podatny? Sposób dodania obsługi php w ten sposób jest w każdym (?) how to w tym temacie...

     

    Więc dlatego jest to niebezpieczne...

  4. Napisano · Raportuj odpowiedź

    Nie znam tego skryptu, tak więc ciężko mi się na ten temat wypowiadać.

     

    Jeżeli w systemie plików struktura skyptu wygląda tak:

    /
|-- /images/
|-- /scripts/
|-- /scripts/index.php
`-- /uploads/

    to wszystko jest OK.[/code]

     

    Rzadko się zdarza.. poza tym, ciągle chodzi o jedną rzecz, zapis w configu nginxa w postacie location ~ \.php$ {} łapie wszystkie pliki php, nie zaleznie gdzie są. Więc nawet jak masz w /images/obrazek.jpg, a skrypty masz w /scripts/index.php dalej obrazek.jpg sie wykona jako php, bo nginx uzyje konfiguracji \.php$

     

    Ale to wymaga przemieszania skryptów perla i PHP wink.gif

     

    wystarczy, ze nginx uzyje konfiguracji \.php$, skrypt perla sie wyswietli, nginx nie ponowi sprawdzenia, i nie zmieni konfiguracji na \.pl$

  5. Napisano · Raportuj odpowiedź

    true - ale to nie zmienia postaci rzeczy, że informacja może się przydać

     

    a dodanie:

     

     	location ~ \..*/.*\.php$ {
	return 403;
	}

     

    Nie zaszkodzi ;)

     

    to tak samo jak z windowsem xp i używania go na koncie z prawem administratora... też proszenie się o problemy, a procent domowych pecetów z xp nie chodzi na administracyjnym koncie jest niewielki.

  6. Napisano · Raportuj odpowiedź

    Oryginalny post: http://www.80sec.com...nx-securit.html

    po "ingliszu": http://www.webhostin...475#post6807475

     

    a po naszemu, jest możliwość wykonania dowolnego kodu php (jak z innymi backendami?).

     

    możliwy model ataku:

    1) prowadzimy hosting obrazków/plików, jest możliwość uploadu plików ogólnie;

    2) ktoś wgrywa plik, plik to obrazek.jpg (nazwa czy rozszerzenie nie istotne) z kodem php;

    3) dowolne wywołanie bezpośrednie pliku http://domain.tld/pl...cosdowlnego.php spowoduje wykonanie spreparowanego pliku;

     

    w zasadzie 99,99% konfiguracji jest podatnych, jak nie cale 100%, np taka:

    location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}

     

    która jest.. wszędzie, w każdym how to itp.

     

    Możliwe formy zabezpieczenia się? Polecam lekturę: http://forum.nginx.o...ead.php?2,88845

     

    // się pośpieszyłem... może miły mod przenieść do działu traktującego o bezpieczeństwie? :>

×