Document document = Jsoup. parse (param);
doc. outputSettings (). escapeMode (EscapeMode. xhtml);
Șir curățat = doc. corp (). text ();

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

intrării

raphaelHuerzeler comentat 20 iunie 2012

Deci, pentru a curăța corect o intrare, ar trebui să faceți:

Document murdar = Jsoup.parseBodyFragment (bodyHtml);
dirty.outputSettings (). escapeMode (EscapeMode.xhtml);
Document clean = new Cleaner (whitelist) .clean (murdar);
Șirul curățat = clean.body (). Html ();

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Acesta este cel mai curat mod, da.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Așteptați: nu v-am văzut folosind „html ()” în ultima linie - nu faceți asta. Utilizați „text ()” - html este pentru intrare care este absolut destinată să conțină HTML. Cred că, în majoritatea cazurilor, nu vrem să avem deloc HTML în intrare, corect?

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Dacă este aplicat corect, va trece orice test XSS pe care îl aruncați. Îndepărtează TOATE codurile HTML.
XSS este HTML care alunecă de la intrare la ieșire. Dacă acest produs de curățare este utilizat în mod corespunzător, toate codurile HTML sunt eliminate.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

raphaelHuerzeler comentat 20 iunie 2012

la naiba - această abordare nu funcționează - nici măcar nu a trecut primul test XSS, așa că practic trebuie să găsesc o modalitate de a permite trecerea unor caractere specifice. dacă acest lucru este pentru a obține cumva acest lucru pentru a încărca o sumă de resurse modificată sau pentru a scrie propria mea metodă de postprocesare care revine orice caractere legitime. Și asta încă nu garantează că nu va deschide un vector de atac.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

raphaelHuerzeler comentat 20 iunie 2012

hmm. Ei bine, diavolul poate fi în detalii - ar trebui să fie ok pentru majoritatea cazurilor în cererea mea. Există totuși mai multe cazuri în care un parametru este scris într-o variabilă javascript direct în jsp - în aceste cazuri nu aveți nevoie de html, prin manipularea șirului puteți obține codul javascript pentru a se executa în acest fel - primul meu gând a fost metode separate (una strict, unul relaxat) de la caz la caz, dar aceasta este o soluție sigură în cel mai bun caz. este ușor posibil să recuperez o variabilă care ar fi fost introdusă prin metoda relaxată într-un cadru în care ar necesita o filtrare strictă. Am câteva idei, dar mai întâi va trebui să fac câteva teste.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

raphaelHuerzeler comentat 20 iunie 2012

Pentru a ilustra - este posibil să se realizeze așa ceva (în cod javascript) cu soluția propusă:
var status = "; alert ('xss'); var xyz = ";

Codul original al paginii era:
var status = ";

Și cererea rău intenționată:
?stare =% 22; alertă (% 27xss% 27);% 20var% 20xyz% 20 =% 20% 22

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Desigur, trebuie să fii conștient de contextul în care te afli.

În Javascript-Context (care se aplică și atunci când scrieți ceva în HTML-Attributes ca „onclick” sau „onmouseover” și altele.) Trebuie să utilizați o strategie complet diferită. Postarea de blog pe care am legat-o ieri pe FB vorbește despre asta în detaliu.
Există un alt articol, a venit cu Nicolas, care descrie de ce nu există o „soluție unică” funcțională pentru a scăpa în diferite contexte. Va trebui întotdeauna să vă asigurați că se face o evadare adecvată pentru contextul actual.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

raphaelHuerzeler comentat 20 iunie 2012

ceea ce mă duce înapoi la sugestia mea inițială de probleme de direcționare în stadiul de ieșire - scopul întregului exercițiu a fost să găsesc o modalitate de a o îndepărta în etapa de intrare;-). deci cred că a revenit la planșa de desen - practic am nevoie de cel puțin 3 procesoare - unul pentru textoutputs în html, unul pentru textoutputs în javascript (inline în jsps) și unul pentru textoutput prin cod javascript (atribuirea valorilor dintr-un json la elementele existente într-o pagină)

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Soluția pe care am sugerat-o scapă doar în context HTML.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

raphaelHuerzeler comentat 20 iunie 2012

da, îmi pare rău, ar fi trebuit să fiu mai precis în ceea ce încercam să realizez, cel puțin înțeleg acum de ce căutați pe UTF-8 (și de ce am fost nedumerit de asta) - Nu am avut niciodată o problemă cu ieșirea în html context, problemele mele au apărut doar în contextul cu 2 javascript pe care l-am descris.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Dacă într-adevăr trebuie să scriem în contextul JS, atunci trebuie să curățăm în ieșire, da.
Acest lucru necesită o atenție suplimentară, deoarece greșirea contextului sau igienizarea într-un mod greșit vor rupe găurile de securitate.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Acestea sunt două aspecte diferite: mă uitam în direcția corectă atunci când v-ați plâns de codificarea Umlauts. Acesta este un set de caractere, care poate fi ocolit folosind metoda pe care am propus-o aici.
Apoi, există problema cu evadarea în contextul JS, care nu are legătură cu traducerea Umlauts în entități (ä etc.) - de data aceasta problema este că JSoup oferă evadarea în contextul greșit.
Mă întreb dacă acest ESApi-Thingy poate avea metode pentru toate contextele posibile.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Pentru a fi clar: m-am înșelat când Jsoup a ghicit setul de caractere greșit, dar în cele din urmă a trebuit să-i spunem lui Jsoup să folosească setul de caractere implicit pentru XHTML (care este UTF-8) pentru a-l opri din a face codificări suplimentare inutile și nedorite pentru „special chars "ca umlautii.

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

raphaelHuerzeler comentat 20 iunie 2012

Am aruncat soluții posibile în cap - s-ar putea totuși să reușim să facem filtrarea parțială a intrărilor - folosind metoda propusă, deoarece ar trebui să scăpăm de orice date problematice atât în ​​contextul html, cât și în contextul json, nu permitem orice intrare html oricum, așa că este bine - singurul lucru de care am avea nevoie este să filtrăm și ieșirea js inline cu o abordare mai strictă, pentru a preveni atacurile de tipul pe care l-am subliniat anterior. Voi face câteva teste și vă voi anunța cum merge. De asemenea, voi migra orice metode rezultate la o clasă de securitate dedicată, astfel încât să putem reutiliza cu ușurință codul respectiv în alte proiecte în viitor - această clasă va conține, sperăm, metode de filtrare pentru orice context, astfel încât pentru proiectele viitoare puteți folosi contextul filtrare adecvată din getgo

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Pentru contextul JS, am putea utiliza Java.Net.URLEncoder în combinație cu HTML-Escaping prin Jsoup ca primă abordare. DAR: Nu sunt 100% sigur, dacă este suficient. Îmi voi oferi rezultatele când voi termina cercetarea acestui bit

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

martin-naumann comentat 20 iunie 2012

Următoarea soluție funcționează remarcabil de bine:

Acest comentariu a fost minimizat.

Copiați linkul Citat răspuns

raphaelHuerzeler comentat 20 iunie 2012

Până în prezent, abordarea filtrării de intrare a tuturor html-urilor (dar lăsând umlauturile neatinse) și efectuarea filtrării stricte a rezultatelor pentru câteva cazuri în care este necesar pare să funcționeze - acum trebuie doar să mă asigur că nu există noi efecte secundare nedorite și să mă asigur că într-adevăr nu trec atacurile din foaia de cheats XSS (cele câteva pe care le-am încercat până acum au scăpat în mod corespunzător)