----- Original Message -----
From: "Marcin Górajec" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 01, 2002 4:26 PM
Subject: [konstrukt] Jak sie zabezpieczac?
[ciach]
> Gdy jednak przyjdzie mi cos zamiescic w Internecie kompletnie nie wiem
co
> zrobic zeby to odpowiednio zabezpieczyc przed dostepem przez
niepowaolane
> osoby/skrypty.
co rozumiesz przez dostep?
> Najbardziej by mnie interesowalo:
> Jakie parametry CHMOD nadac plikowi, aby byl bezpieczny i jak je zdjac,
aby
> moc wykozystac ten plik. (lepsze 666 czy moze 777).
> Jak, gdzie przechowywac pliki z danymi? W katalogu ze skryptem, w
> podkatalogu, czy w jedym "zbiorczym" razem z innymi waznymi plikami.
po pierwsze doczytac o uprawnieniach plikow w *xach ;)
777 to mozliwosc zapisu/odczytu/wykonywania pliku dla wszyskich jak
leci ( wlasciciel, grupa, inni ) tak wiec najlepiej bedzie przynajmniej
uniemozliwic innym zapis do pliku, chyba ze sam potrzebujesz cos do niego
zapisywac.
co do reszty podstawowych zabezpieczen to trzeba przyjac, ze zawsze
znajdzie sie ktos kto bedzie chcial cos zepsuc/zniszczyc/zmienic sposob
dzialania
tak wiec wszystkie hasla itp itd najlepiej umiescic poza DocRootem -
nikt Ci go nie podejrzy wpisujac urla w przegladarce albo umieszczac je w
pliku ktory po wywolaniu bedzie parsowany - po wywolaniu pokaze sie nic :>
a najlepiej jedno i drugie ;)
kolejna sprawa to wylaczenie informacji o bledach error_reporting(),
lub ustawienie tego tylko na okreslonego usera/hosta/klase
uzywajac wyswietlania zawartosci serwisu przy pomocy include(),
require(), fopen() przy pomocy url`a ogranicz rodzaj/liczbe wyswietlanych
plikow - nikt nie podejrzy sobie katalogow i plikow, ktorych nie chcesz
pokazac ( /etc/passwd, /proc itd )
generalnie gdy dzialanie programu uzalezniasz od parametrow
przekazanych przez url/uzytkownika dobrze jest sprawdzac jaka to zmienna
( oprzec program na odpowiednich wywolaniach case ) - jakiego jest typu,
z jakiego przedzialu itd. zabezpieczajac sie w ten sposob nikt nie bedzie
mogl z serwera zrobic sieczki ;)
co do sql`a to uzywac mozliwosci jakie oferuje - przykladowo jesli
serwis ma tylko charakter informacyjny to ograniczyc uzytkownikowi na
ktorym dziala serwis mozliwosc wszelkich delete, drop table/database itd,
w przypadku mozliwosci kasowania ( na przyklad uzytkownika z listy
wysylkowej ) sprawdzac wprowadzony string uniemozliwiajac wykonanie
komendy typu delete from newsletter where email=* itd itd
to podstawy, generalnie nie ma zadnych uniwersalnych rad - po prostu
trzeba przewidywac _wszelkie_ mozliwosci ( nawet wydajace sie pozornie
absurdalne ) i zabezpieczac sie na wszelkie mozliwe sposoby, a i tak
czasem popelni sie blad.
niebieski
--
KONSTRUKTywna lista dla KONSTRUKTorow stron www
http://konstrukt.prv.pl [EMAIL PROTECTED]
