Bezpieczenstwo - formularz logowania, pamietanie hasla, xss, csrf[dlugie]
Stefan - 04-06-2010 22:35
Bezpieczenstwo - formularz logowania, pamietanie hasla, xss, csrf[dlugie]
p.c.www (FUT), p.c.l.javascript
Heja, mam pytanie o wasza opinie nt. pewnej kwestii
Zaimplementowalem na pewnej stronie, mozliwosc wczytania niektorych
podstron 'modalnie' - tj.
- bez js link dziala normalnie,
- z js link jest otwierany w dolozonym divie, ktory symuluje modalne
okienko (przyslaniajac reszte tresci strony).
Oczywiscie oprogramowanie podsyla wersje modalna bez naglowkow itd.
rzeczy - wszystko zgodnie z XHTML.
Teraz do sedna - w przypadku modalnego linku do formularza logowania:
- Firefox, mimo ze umozliwia zapamietanie hasla, nie wypelnia
automatycznie pol dolozonych do dokumentu po pierwszym zinterpretowaniu DOM.
- Chrome nie umozliwia w ogole zapamietywania hasla w takim formularzu.
Uzytkownicy chca tej funkcji. Z tego co sie orientuje to sa dwa wyjscia:
- iframe zamiast div z trescia ladowana ajaxem,
- przechowywanie tych formularzy w pierwszym DOMie wysylanym do
przegladarki.
Pierwszego nie chce - jest niezgodne z XHTML i ogolnie ble. A druga
metoda otwiera wektor ataku CSRF. W koncu formularz (wypelniony przez
przegladarke) caly czas siedzi gdzies w DOMie i moze byc odczytany przez
wstawiony javascript.
Olac to i zrobic to tą metoda? A moze jest jeszcze inny sposob?
Peter May - 04-06-2010 22:35
W dniu 2010-05-23 19:58, Stefan pisze:
> p.c.www (FUT), p.c.l.javascript
>
> Heja, mam pytanie o wasza opinie nt. pewnej kwestii
>
> Zaimplementowalem na pewnej stronie, mozliwosc wczytania niektorych
> podstron 'modalnie' - tj.
>
> - bez js link dziala normalnie,
> - z js link jest otwierany w dolozonym divie, ktory symuluje modalne
> okienko (przyslaniajac reszte tresci strony).
>
> Oczywiscie oprogramowanie podsyla wersje modalna bez naglowkow itd.
> rzeczy - wszystko zgodnie z XHTML.
>
>
> Teraz do sedna - w przypadku modalnego linku do formularza logowania:
>
> - Firefox, mimo ze umozliwia zapamietanie hasla, nie wypelnia
> automatycznie pol dolozonych do dokumentu po pierwszym zinterpretowaniu
> DOM.
>
> - Chrome nie umozliwia w ogole zapamietywania hasla w takim formularzu.
>
>
> Uzytkownicy chca tej funkcji. Z tego co sie orientuje to sa dwa wyjscia:
>
> - iframe zamiast div z trescia ladowana ajaxem,
> - przechowywanie tych formularzy w pierwszym DOMie wysylanym do
> przegladarki.
>
> Pierwszego nie chce - jest niezgodne z XHTML i ogolnie ble. A druga
<iframe> działa dla XHTML-a Transitional, a nie piszesz o wersji
XHTML-a. Z resztą nawet dla XHTML Strict powinien zadziałać, o ile
pamiętam nawet w poprawnym trybie application/xhtml+xml (mogę się mylić,
trzeba to sprawdzić). Idealnie by było użyć <object> zamiast <iframe>,
ale jest tak zbudowana implementacja w różnych przeglądarkach, zwłaszcza
w IE, że trzeba zrezygnować z <object>.
Z resztą zrezygnuj z XHTML-a na rzecz HTML5 i <iframe> jest dostępny:
http://www.whatwg.org/specs/web-apps...e-element.html
> metoda otwiera wektor ataku CSRF. W koncu formularz (wypelniony przez
> przegladarke) caly czas siedzi gdzies w DOMie i moze byc odczytany przez
> wstawiony javascript.
>
> Olac to i zrobic to tą metoda? A moze jest jeszcze inny sposob?
A może daj checkboksa do zapamiętania loginu i hasła w cookie?
--
Peter
=?ISO-8859-2?Q?Piotru=B6?= - 04-06-2010 22:35
On 23 Maj, 19:58, Stefan <ste...@costam.wp.pl> wrote:
> Pierwszego nie chce - jest niezgodne z XHTML i ogolnie ble.
No wiadomo
> A druga
> metoda otwiera wektor ataku CSRF. W koncu formularz (wypelniony przez
> przegladarke) caly czas siedzi gdzies w DOMie i moze byc odczytany przez
> wstawiony javascript.
Ale przecież taką samą sytuację masz jeżeli jest to zwykły formularz
otwierany "normalnie"
Piotrek
Stefan - 04-06-2010 22:35
Piotruś pisze:
>> A druga
>> metoda otwiera wektor ataku CSRF. W koncu formularz (wypelniony przez
>> przegladarke) caly czas siedzi gdzies w DOMie i moze byc odczytany przez
>> wstawiony javascript.
>
> Ale przecież taką samą sytuację masz jeżeli jest to zwykły formularz
> otwierany "normalnie"
Chyba ze formularz jest innej domenie, tak jak to realizuje przy
logowaniu Google.
--
http://www.artveo.pl/
Borys =?iso-8859-2?Q?Pogore=B3o?= - 04-06-2010 22:35
Dnia Sun, 23 May 2010 19:58:43 +0200, Stefan napisał(a):
> - iframe zamiast div z trescia ladowana ajaxem,
> - przechowywanie tych formularzy w pierwszym DOMie wysylanym do
> przegladarki.
>
> Pierwszego nie chce - jest niezgodne z XHTML i ogolnie ble.
Ale ten XHTML masz z jakiegoś konkretnego powodu, czy tylko tak dla zasady
sobie życie utrudniasz? :)
--
Borys Pogoreło
borys(#)leszno,edu,pl
porneL - 04-06-2010 22:35
On Sun, 23 May 2010 18:58:43 +0100, Stefan <stefan@costam.wp.pl> wrote:
>
> Uzytkownicy chca tej funkcji. Z tego co sie orientuje to sa dwa wyjscia:
>
> - iframe zamiast div z trescia ladowana ajaxem,
> - przechowywanie tych formularzy w pierwszym DOMie wysylanym do
> przegladarki.
>
> Pierwszego nie chce - jest niezgodne z XHTML i ogolnie ble.
Ble (szczególnie cofanie UI do ery modalnych aplikacji jest ble), ale
mylisz XML ze Strict DOCTYPE. http://pornel.net/xhtml
> A druga metoda otwiera wektor ataku CSRF. W koncu formularz (wypelniony
> przez przegladarke) caly czas siedzi gdzies w DOMie i moze byc odczytany
> przez wstawiony javascript.
To, jak jest serwowany formularz nie ma wiele wspólnego z CSRF. Ważne
jest, jak jest odbierany.
Może chodzi ci o atak XSS? Jak masz luki XSS, to i tak masz przerąbane, bo
atakujący może ci też popodmieniać standardowe funkcje przeglądarki,
podstawić fałszywy formularz, dłubać we wszystkich ajaxach, ramkach z tej
samej domeny, itd.
Wstaw normalny formularz, a w nim jakiś niezgadywalny token i będzie ok.
--
http://pornel.net
this.author = new Geek("porneL");
porneL - 04-06-2010 22:35
On Sun, 23 May 2010 22:55:16 +0100, Peter May <peter.may@onet.pl> wrote:
>> Pierwszego nie chce - jest niezgodne z XHTML i ogolnie ble. A druga
>
> <iframe> działa dla XHTML-a Transitional, a nie piszesz o wersji
> XHTML-a. Z resztą nawet dla XHTML Strict powinien zadziałać, o ile
> pamiętam nawet w poprawnym trybie application/xhtml+xml (mogę się mylić,
> trzeba to sprawdzić).
Działa. Przeglądarki nie bawią się w tak pedantyczne wyłączanie rzeczy na
postawie DOCTYPE (tabelki działają z DOCTYPE HTML 3.2, iframe + target
działa z DOCTYPE Strict, wszystkie rzeczy z HTML5 działają z DOCTYPE
HTML4, itd.)
Rodzaj parsera i XML DOM na ramki specjalnie nie wpływa.
> Idealnie by było użyć <object> zamiast <iframe>, ale jest tak zbudowana
> implementacja w różnych przeglądarkach, zwłaszcza w IE, że trzeba
> zrezygnować z <object>.
Nie było by idealnie, tylko tak samo albo gorzej. Przeglądarki wyświetlają
HTML w <object> za pomocą <iframe>.
> A może daj checkboksa do zapamiętania loginu i hasła w cookie?
Jak już co, to hasha hasła.
--
http://pornel.net
this.author = new Geek("porneL");
Peter May - 04-06-2010 22:35
W dniu 2010-05-25 23:21, porneL pisze:
> On Sun, 23 May 2010 22:55:16 +0100, Peter May <peter.may@onet.pl> wrote:
>
>>> Pierwszego nie chce - jest niezgodne z XHTML i ogolnie ble. A druga
>>
>> <iframe> działa dla XHTML-a Transitional, a nie piszesz o wersji
>> XHTML-a. Z resztą nawet dla XHTML Strict powinien zadziałać, o ile
>> pamiętam nawet w poprawnym trybie application/xhtml+xml (mogę się
>> mylić, trzeba to sprawdzić).
>
> Działa. Przeglądarki nie bawią się w tak pedantyczne wyłączanie rzeczy
A szkoda ;-) Może paru "mistrzów sieci web" zaczęłoby wreszcie poprawiać
napisany przez siebie kod.
> na postawie DOCTYPE (tabelki działają z DOCTYPE HTML 3.2, iframe +
> target działa z DOCTYPE Strict, wszystkie rzeczy z HTML5 działają z
> DOCTYPE HTML4, itd.)
>
> Rodzaj parsera i XML DOM na ramki specjalnie nie wpływa.
Fakt. Dokumentacja nie rzadko mówi "deprecated", i tak wszystko działa :/
>> Idealnie by było użyć <object> zamiast <iframe>, ale jest tak
>> zbudowana implementacja w różnych przeglądarkach, zwłaszcza w IE, że
>> trzeba zrezygnować z <object>.
>
> Nie było by idealnie, tylko tak samo albo gorzej. Przeglądarki
> wyświetlają HTML w <object> za pomocą <iframe>.
A to ciekawe. Sądziłem, że <object type="text/html"> renderuje się
"swoim torem", a tak jest <iframe>?
Nie jestem teraz pewien, ale czy kiedyś nie chciano porzucić <iframe>-a
na rzecz <object>?
>> A może daj checkboksa do zapamiętania loginu i hasła w cookie?
>
> Jak już co, to hasha hasła.
Trafna uwaga.
--
Peter
Colin - 04-06-2010 22:35
On 2010.05.25 23:21, porneL wrote:
> Jak już co, to hasha hasła.
Możliwe że bezpieczniej jest nie hashować haseł w cookie.
Jak ktoś zna hash hasła (ukradł z bazy w jakiś sposób), ale nie zna
samego hasła, to nie powinien mieć możliwości zalogowania się.
Oczywiście można hashować hasło złączone z jakimś ciągiem ustawionym w
konfiguracji, ale wiadomo jak to jest w praktyce - połowa adminów nie
zmieni tego ustawienia, jak to jest w WordPressie.
porneL - 04-06-2010 22:35
On Fri, 28 May 2010 21:38:07 +0100, Colin <colin@colin.tk> wrote:
>> Jak już co, to hasha hasła.
>
> Możliwe że bezpieczniej jest nie hashować haseł w cookie.
>
> Jak ktoś zna hash hasła (ukradł z bazy w jakiś sposób), ale nie zna
> samego hasła, to nie powinien mieć możliwości zalogowania się.
Ale nikt ci nie każe naśladować błędów WordPressa :)
$salt = random();
$cookie = $salt . hash($password . $salt);
Można by jeszcze do hasha dorzucić datę ważności i wersję cookie z bazy,
żeby nie dało się przedłużać życia cookie i żeby dało się unieważnić
wszystkie istniejące hashe jedną zmianą w bazie.
--
http://pornel.net
this.author = new Geek("porneL");