izvairīšanās no XSS uz viena domeina subdomeiniem.

[codez]

Tātad lieta tāda, ka uz viena domeina tiek veidotas vairākas web aplikācijas ar atsevišķiem subdomeiniem, kur dažādas aplikācijas veido citi cilvēki, tāpēc svarīgi ir panākt, lai projekts A būtu pilnībā aizsargāts no XSS, ja projektā B ieviesusies XSS ievainojamība.

 

Pagaidām pamatdoma ir:

1) neļaut lapas lādēt freimos, kā gadījumā ar skriptu uzreiz pārlādē parenta location;

2) paralēli tam servera pusē testē referrer-a adresi uz datu postošanu.

 

Vai kāds ir saskāries ar līdzīgām problēmām un varbūt var atklāt savus "know how" noslēpumus?

 

========

EDIT: nevis uz subdomeiniem, bet viena domeina ietvaros uz dažādām mapēm.

Piemēram:

http://mansdomeins.lv/aplikācija-a

http://mansdomeins.lv/aplikācija-b

Edited October 6, 2009 by codez

[Web Developer]

Kāds sakars?

Lai novērtu samazinātu ievainojamību risku, piespied programmētājus programmēt konkrētā frameworkā pēc konkrētiem noteikumiem un paņēmieniem. Liec viņiem kodēt "konveijera" stilā un pats čeko kvalitāti.

Un ja aplikācijas ir dažādas, tad dažādi arī ir lauki, datubāzes, paroles, ne tā? Vai arī, ja tās ir simetriski, simetriski arī labo un attīsti.

[briedis]

Te man liekas izpildās likums - ķēde ir tik stipra, cik tās vājākais posms :)

[codez]

No atbildes sapratu tikai to, ka Web Developers nezin, kā zem viena domeina izsargāties no XSS pārējām aplikācijām, ja viena no aplikācijām ir kļūdaina.

Un vēl, WebDeveloper, padomā kā tu piespiedīsi 3-šās puses programmētājus neielaist ievainojamības.

[Aleksejs]

WebDeveloper, bet viņš taču ļoti skaidri teica:

"Vai kāds ir saskāries ar līdzīgām problēmām un varbūt var atklāt savus "know how" noslēpumus?"

 

Jautājums ir par manu, Tavu vēl kāda cita foruma apmeklētāja praktisko pieredzi šīs problēmas risināšanā.

 

Viena no perspektīvām lietām, kura titiko sāk attiīstīties ir CSP:

http://people.mozilla.org/~bsterne/content-security-policy/index.html

 

No šobrīd pieejamām lietām vēl ir dažādas egress filtrācijas metodes webserverī (respektīvi pirms izdošanas klientam izvaddati tiek, piemēram, pakļauti validācijai pret lapas šablonu). Ar tām esmu nedaudz darbojies, taču ne tik lielā mērā, lai kaut ko saturīgu spētu pastāstīt vai parādīt.

[krikulis]

Cepumiem var likt ceļus, kuros jamie ir aktīvi (netiks klāt +document.cookie)

CSRF pasargās + referera čekošana datu postošanai.

[codez]

kirkuli, vislielākā problēma ir tāda, ka tiek izveidots ifreims ar otras aplikācijas kādu lapu un šī ifreima saturam tad arī var piekļūt ar skriptu, jo tie atrodas uz viena domeina.

[krikulis]

if(top !== self) top.window.location.href = self.location.href

ielikt kādā no visur izmantotiem JS libiem (jQuery source f.e.) un miers.

[marrtins]

kirkuli, vislielākā problēma ir tāda, ka tiek izveidots ifreims ar otras aplikācijas kādu lapu un šī ifreima saturam tad arī var piekļūt ar skriptu, jo tie atrodas uz viena domeina.

Šāds gļuks eksistē inbox.lv. Pirms ~pieciem-sešiem gadiem uzķēru. Tad lika izvākt rakstu no interneta, draudēja ar policiju, hosteri gandrīz atslēdza serveri, bet pirms kāda gada vēl skatījos un nebija salabots (nezinu kā tagad). Reāli varēj ņemties pa to viņu kontrol paneli - uzstādīt forwardus utt.

 

Bet reāli baigi ķēpīgais pasākums, šādus XSS novērst, kamēr neviens ar pirkstu neiebaksta kur kas un kā... (Izņemot, protams, inbox.lv, kuriem, acīmredzot, pofigs)

[codez]

if(top !== self) top.window.location.href = self.location.href

ielikt kādā no visur izmantotiem JS libiem (jQuery source f.e.) un miers.

 

Diemžēl šo var elementāri apiet šādi:

$('body').append('<iframe id="f" src="/b/test7_mainb.php"></ iframe>');
f=$('#f').get(0);
f.contentWindow.top=f.contentWindow;

 

Iframe scripti vēl nav palaidušies, bet iframe top mainīgais nomainīts uz paša iframe-s window-u.