Aleksejs Posted August 12, 2008 Report Share Posted August 12, 2008 Sveiki! Nevarēju īsti atrast vietu, kur šo tēmu ielikt, tādēļ izlēmu ielikt pie pārlūku savietojamības problēmām, tādēļ ka pagaidām (ja pareizi saprotu šo iespēju atbalsta tikai firefox) pārlūkiem nav šīs iespējas. Un, nu par lietu: Lasot pēdējo Linux Magazine numuru iekrita acīs atsauce uz šo lapu: Site Security Policy Ideja ir sekojoša: Web serverī izveido speciālu aprakstu tam: 1. No kādiem domēniem ir pieejami klienta skripti (JavaSccript) 2. Kādi domēni var būt kā avots (piemēram, kuros var būt forma), kas nosūta uz šo domēnu parametrus (ar ne GET vai HEAD metodēm) 3. Domēni, uz kuriem var tikt veikti XSS pieprasījumi no konkrētās padotās lapas 4. Atskaites URI - adrese, kurp pārlūkam jāsūta paziņojumi par pārkāpumiem uzstādītajos noteikumos. Šī visa lieta vēl ir tikai izstrādes stadijā, taču domāju, ka tā neapšaubāmi ir ļoti apsveicama ideja. Vai kādam ir zināmas alternatīvas šai idejai? Varbūt kādas pārdomas? Quote Link to comment Share on other sites More sharing options...
blackhalt Posted August 12, 2008 Report Share Posted August 12, 2008 Itzik Kotler Jinx - Malware 2.0 Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted August 12, 2008 Author Report Share Posted August 12, 2008 Fascinating... Varbūt vari ielikt pilnu viņa uzstāšanās tekstu - uzreiz neatradu. Un varbūt varētu arī pakomentēt kaut ko vairāk. Quote Link to comment Share on other sites More sharing options...
4e4en Posted August 22, 2008 Report Share Posted August 22, 2008 (edited) Uz savas lapas esmu uzlicis pāris (KB lielu) mod_rewrite, kas bloķē gandrīz visas draņķības + pielogo tās. Bloķē visus greizos pieprasījumus, pieprasījumus, kuri satur SQL Inj, sliktos simbolus, RFI, LFI, XSRF. un daudz ko citu. Rezultātā sanāk, ka man ir uzlikts kaut kas līdzīgs PHP FireWall Script. Droši drīksti mēģināt uzlauzt malware.lv :) Salīdzini piem: http://php.lv/f/?x=' union select * from users /* ar http://malware.lv/forum/?x=' union select * from users /* pirmajā gadījumā pieprasījums tiek apstrādāts, otrajā tiek ielogots un pāradresēts uz index lapu. Edited August 22, 2008 by 4e4en Quote Link to comment Share on other sites More sharing options...
andrisp Posted August 22, 2008 Report Share Posted August 22, 2008 Kā tu zini, ka pirmajā variantā tiek apstrādās ? Man acīm izskatās, ka vienkārši ignorēts. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted August 22, 2008 Author Report Share Posted August 22, 2008 4e4en, jā, tas protams ir forši... Bet vai Tev ir arī kādi komentāri attiecībā uz site security policy? :) Pad mod_rewrite runājot: 1) Vai pāris KB fails neslogo sistēmu? 2) Vai ir izdevies izveidot analoģiju ar "permit allowed1; permit allowed2; ... permit allowedN; drop all;" vai arī viss ir līmenī "drop bad1; drop bad2; ... drop badN; permit all;' 3) Vai mod_security nebūtu piemērotāks rīks "sliktību" apstrādei logošanai utt, jo tomēr mod_rewrite nodarbojas tikai ar GET/HEAD. Quote Link to comment Share on other sites More sharing options...
4e4en Posted August 23, 2008 Report Share Posted August 23, 2008 (edited) mod_security pats nav nemaz tik drošs. Ir redzētas smukas filmiņas, kur ir serveris ar mod_security, bet tik un tā tiek iznests caur SQL Inj, caur _GET parametriem. Edited August 24, 2008 by 4e4en Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted August 23, 2008 Author Report Share Posted August 23, 2008 Pag, mod_rewrite, vai mod_security? Quote Link to comment Share on other sites More sharing options...
4e4en Posted August 24, 2008 Report Share Posted August 24, 2008 (edited) mod_security. Man ar mod_rewrite problēmas nav bijušas. Edited August 24, 2008 by 4e4en Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted August 25, 2008 Author Report Share Posted August 25, 2008 Nu, jā, bet mod_rewrite nespēj filtrēt POST/COOKIE datus, ko ar tiem darīt? Manuprāt, tieši šim mērķim mod_security arī būtu piemērots... Quote Link to comment Share on other sites More sharing options...
4e4en Posted August 25, 2008 Report Share Posted August 25, 2008 es nefiltrēju POST datus, jo man uz tā domēna forums sēž, bet COOKIE gan tiek pārbaudīti pamēģini ieiet malware.lv, un piem. kādu no cepumiņiem nomainīt uz: <script>alert(document.cookie);</script> Cik es atceros, tad vainu tevi visu laiku redirectos, vai arī parādīs 403 lapu. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted August 25, 2008 Author Report Share Posted August 25, 2008 Nu, redz, bet ar mod_security taču varētu arī no POST datiem izvākt ļaunos simbolus un nelaist sliktos POST datus pat pieskarties PHP daļai. Jā, extrusion detection ir laba lieta. Bet vai vari kādu viedokli pateikt par Site Security policy? ;) Quote Link to comment Share on other sites More sharing options...
Roze Posted August 25, 2008 Report Share Posted August 25, 2008 .. tādēļ ka pagaidām (ja pareizi saprotu šo iespēju atbalsta tikai firefox) pārlūkiem nav šīs iespējas. Ja uz to skatās vispārīgi tad faktiski nav pat īsti svarīgi vai konkrēto security fīču kāds pārlūks atbalsta vai neatbalsta, JO vienmēr būs lietotāji ar vecākām/citām pārlūku versijām.. Vienmēr kaut kādus pieprasījumus varēs veidot ("kraftēd") bez pārlūka kā tāda.. Vai kādam ir zināmas alternatīvas šai idejai? Varbūt kādas pārdomas? No php viedokļa kā transparentus risinājumus var idejiski minēt divus.. hardened php ( http://www.hardened-php.net/ ) kas tev drošivien ir zināms.. Bet samērā jauna fīča ir PHP Taint .. http://wiki.php.net/rfc/taint Faktiski no kurienes nāk formas posts (vai tas ir cits domēns) praktiski ir vienalga un idejiski jau sanāk apstrādāt citā līmenī.. Quote Link to comment Share on other sites More sharing options...
Aleksejs Posted August 26, 2008 Author Report Share Posted August 26, 2008 Ja uz to skatās vispārīgi tad faktiski nav pat īsti svarīgi vai konkrēto security fīču kāds pārlūks atbalsta vai neatbalsta, JO vienmēr būs lietotāji ar vecākām/citām pārlūku versijām.. Vienmēr kaut kādus pieprasījumus varēs veidot ("kraftēd") bez pārlūka kā tāda.. Hmm... Ne gluži, manuprāt. Šai lietai mērķis ir nevis aizsargāt serveri, bet gan pārlūku, kas atbalsta SSP. Šobrīd pārlūks izpilda pilnīgi visu, ko saņem, taču ar SSP ir iespēja pārlūkam (tādam, kas šo lietu atbalsta) paziņot visus pieļaujamos skriptus un to izcelsmes vietas. Analoģiski, kā favicon.ico - ne visi pārlūki to atbalsta, bet tie, kas atbalsta šo lietu var izmantot. Šis ir papildus slānis kopējā drošības pasākumu kopumā, kas papildina pārējos, taču neaizvieto tos. Respektīvi - šī lieta nerisina problēmu, ka kāds var speciāli ģenerēt ("kraftēt" :D ) pieprasījumus serverim no specializētas programmatūras, bet gan to, ka padodot "kraftētu" lapu klienta pārlūkam, pārlūks neizpildīs tajā esošo skriptu, jo šis skripts nebūs iekļauts "uzbrukuma mērķa lapas" SSP atļauto skriptu sarakstā. No php viedokļa kā transparentus risinājumus var idejiski minēt divus.. hardened php ( http://www.hardened-php.net/ ) kas tev drošivien ir zināms.. Bet samērā jauna fīča ir PHP Taint .. http://wiki.php.net/rfc/taint Faktiski no kurienes nāk formas posts (vai tas ir cits domēns) praktiski ir vienalga un idejiski jau sanāk apstrādāt citā līmenī.. PHP Taint - biju dzirdējis, bet netiku izmantojis - izskatās sakarīgi. Būs jāizmēģina. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.