Jump to content
php.lv forumi

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


codez

Recommended Posts

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 by codez
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...