Zdravím, mnohem užitečnější pro SQL bude použít PreparedStatement, kde se o escapování nemusíte starat. Pouhé nepovolení apostrofu může být málo – jednak různé dialekty SQL mohou používat různé způsoby escapování (a může tak existovat jiný způsoba, jak se do SQL vlámat), jednak někdy může být apostrof součástí vstupních dat. Testování, zda se místo metody POST nepoužila GET, patří podle mne už k těm zbytečným opatřením. Testování na počet parametrů a přesnou shodu jména je v Javě už úplně mimo – Java Servlety nejsou staré verze PHP :-) Parametry navíc ničemu neublíží, pouze budou v nějaké mapě a aplikace je nikdy nebude číst. Pokud aplikace nějaký parametr čte, použije jeho název jako klíč, tudíž nějaké podobné názvy opět nevadí. Jediný problém by mohl nastat, pokud by nějaký framework vkládal mapy atributů a parametrů do jednoho kontextu a parametry měly přednost, nebo jste někdy atribut zapomněl nastavit a útočník by nastavil stejnojmenný parametr. Ovšem framework, ktreý by něco takového dělal, neznám, a nepovažoval bych ho za moc zdařilý – parametry má zpracovat servlet (který k nim bude přistupovat přímo a nemohou se mu splést s atributy), a případný sdružený kontext pro view už by měl obsahovat jen atributy, které nastavil servlet.
Filip Jirsák 2007/10/21, Ivan 596 <[EMAIL PROTECTED]>: > > Ranko, > > mohol by sa prosim nejaky bezpecnostny specialista podelit o kroky > PROGRAMATORA pre bezpecnu java web aplikacie? > > Uvediem svoje (aplikacia je klasicky java-web, jsp, servlet, EE ziadne, > mozno neskor, Struts): > > 0. Prihlasovanie odosielane cez POST-metodu :-) > 1. SSL sifrovana komunikacia (to ale asi nie je programtorova starost...) > 2. Osetrenie formularovych vstupov > - pre SQL (ak mam v programe kazdy parameter osetreny > apostrofmi:String dotaz = "SELECT * FROM nieco WHERE id='" + id "', staci > vlastne len nepovolit vo formularovom vstupe jediny znak: apostrof?) > - treba pre nieco ine osetrovat formularove vstupy, ktore sluzia len > databaze? > 3. Kazda stranka (okrem prihlasovacej) na zaciatku testuje ci existuje > session s id uzivatela, teda iba uz prihlaseny mozu pristupovat > 4. Testovanie vsade, kde sa neocakvaju GET parametre, ci je metoda POST > 5. Osetrovanie parametrov, napr. ak ocakavam jediny, nieco ako if ( ( > request.getParameterMap().size!=1) spolu s testovanim presneho mena a > hodnoty > > > oplati sa este nieco?? > -- Filip Jirsák [EMAIL PROTECTED]
