Diskuze: Bola by takáto web aplikácia bezpečná?
V předchozím kvízu, Online test znalostí JavaScript, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 12 zpráv z 12.
V předchozím kvízu, Online test znalostí JavaScript, jsme si ověřili nabyté zkušenosti z kurzu.
Má to byť web applikácia na obchodovanie s kryptomenami.
napis mi pak prosim nazev, at se tomu vyhnu (y)
To by bolo najideálnejšie, ale to nepôjde. Jedna z požiadaviek je, že tam má byť chat. Ale tak myslím si, že chat do ktorého budem apendovať nejakú značku, do ktorej text vložím pomocou textContent, by nemala umožniť XSS, apka by mala ostať aj tak bezpečná.
A ja vraj rýpem... 
Ako
to bolo v Limonádový Joe? Vy vrtáku?...
Tak, měl bys tu aplikaci psát tak, aby žádný XSS filtr nepotřebovala, používat jej případně jako doplněk ochrany, ne jako hlavní bariéru.
Ty technologie jinak neznám, takže nedokážu posoudit jejich bezpečnost, ale pokud hádám správně, řídíš se přístupem, že vše bude šifrování díky SSL, a tak chráněno před zlýma očima ošklivého útočníka.
S kryptoměnami neobchoduju, ale tak nějak mi přijde, že by se návštěvníkům líbilo lézt do takové aplikace skrz Tor/VPN, což v zásadě implikuje vypnutý/omezený JS atd.
To nie je hlavná bariéra. Ale akonáhle do stránky vkladáš akýkoľvek vstup, mal by prejsť sanitizáciou na serveri a až potom ho vkladať do stránky. To je bežná prax, nie hlavná bariéra. Ako hlavná bariéra je tam skôr využitý secure websocket, miesto GET/POST. To má zabrániť CSRF. A Tor/VPN - prístup do web aplikácie cez VPN či Tor je samozrejme možný, ale vypínať JS vo web aplikácii je nezmysel. To isté čo JS mi o prehliadači zistí aj ktorýkoľvek backend - či už PHP, Perl, Python, Ruby, či Benčatov milášek. Jediná stránka na ktorej sú hlavičky nepodstatné, je statická stránka s vypnutým JS. A statickou stránkou web apku proste nejde urobiť. Navyše, užívateľ nemá šancu dozvedieť sa, či je stránka statická, alebo ju vygeneroval nejaký jazyk na serveri. To je proste nezmysel, tak sa to nerobí, ani na to nie je žiadny rozumný dôvod.
Hodně výjimečně se sanitizuje při vstupu,.. v 99% případů se sanitizuje až při použití (tj na výstupu). Pokud tedy ty informace ze serveru -> do clienta mají chodit přes web sockety, tak si je sanitizuje až javascript. Pokud ti data na webu bude renderovat server (jakože u tebe nebude), tak je sanitizuje server při renderování html do responsu.
To aj mám na mysli. Nemá zmysel sanitizovať dáta priamo na vstupe, čiže na klientovi pre poslaním na backend, lebo to obíde každé decko. Ale až keď dorazia na server. Na serveri ich následne uložiť do Mongo "as is", lebo chcem mať prehľad o tom, kto sa o čo pokúšal, hneď na to ich sanitizovať cez yahoo XSS filter knižnicu a potom poslať cez websocket klientom do četovacieho okna. A aj na klientovi ich vkladať ako element.textContent, nie element.innerHTML. Tak by to malo byť prakticky nepriestrelné riešenie. Teda čo sa XSS týka... CSRF zasa nebude natívne možné, lebo backend nepočúva na žiadny POST, ale len na websockety. Tým pádom CSRF nevie vyvolať falošnú akciu. Ale vie ju vyvolať CLICKJACKING. Práve preto bude aplikovaná CSP politika a podporované budú len prehliadače, ktoré majú podporu CSP. Plus websockety budú zabezpečené tak, každý klient si bude so serverom odovzdávať aj jedinečný token, čo je odporúčaná praktika na zabezpečenie wss. So far, so good...
Jediné čo mi robí starosti je, že na autentifikáciu chcem použijem JWT - JSON Web Tokens a nie klasické riešenie sessions na serveri a cookie so session id na klientovi. Prečo? Lebo bude existovať jediná stránka, v princípe index.html, ktorá natiahne do prehliadača celú web aplikáciu a následne začne táto web aplikácia komunikovať so serverom výlučne cez wss. Žiadny POST, GET, žiadny REST. Čiže ani žiadne cookies, tým pádom žiadne sessions. A tým pádom aj autentifikácia cez wss a to s využitím JWT. No a tu si nie som istý bezpečnosťou, lebo som videl nejakú, a nie jednu, kritiku JWT a odporúčania nepoužívať túto technológiu na autentifikáciu. Lenže, nič z toho čo som čítal mi neprišlo ako skutočný problém, nevidím žiadny pádny argument nepoužiť JWT a localStorage, miesto sessions a cookies...
Ak to zhrniem - v apke podľa mojej predstavy nebude hroziť XSS, ani CSRF - iba clickjacking predstavuje hrozbu, čiže falošná akcia pomou iframe. A ten zas chcem odstaviť CSP 2 politikou, konkrétne frame-ancestors direktívou. Ale JWT, tam ma zneistili tou kritikou. Ja tam síce žiadny problém nevidím, ale trochu ma predsalen zneistili. Preto toto vlákno - vie niekto o niečom konkrétnom v takto zabezpečenej apke na čo by som si mal dať pozor? Nejaký vektor útoku ktorý otvára JWT? Alebo aspoň o nejakých best practices, keď už bude použité JWT? Alebo vie niekto o nejakom dodatočnom zabezpečení? Napríklad o nejakom vhodnom Node WAF? Proste urobil by niekto niečo inak, či navyše?
ale vypínať JS vo web aplikácii je nezmysel. To isté čo JS mi o prehliadači zistí aj ktorýkoľvek backend
Argument paranoidních lidí je takový, že se backend o prohlížeči dozví jen to, co mu řekne klient. Pokud je na klientovi možné vykonávat, řekněme, libovolný kód, může zjřemě získat více informací než v opačném případě. To byla celá moje pointa. Chápu, že v dnešní době se hodně věcí řeší přes JS/... na klientovi, a tak se vypnutí JS zdá být nesmysl.
Pokud bude hlavní část v zásadě na klientovi, je jen třeba býti k jeho datům opatrný, to je celé (kdo ví, zda si klient onen kód nějak neupravil mezi tím, kdy jej ze serveru dostal a kdy jej spustil). Ale počítám, že to je ti jasné.
Zobrazeno 12 zpráv z 12.