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?

do góry

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/current-work/mu
ltipage/the-iframe-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

do góry

On 23 Maj, 19:58, Stefan <s...@c...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

do góry

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/

do góry

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

do góry

On Sun, 23 May 2010 18:58:43 +0100, Stefan <s...@c...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");

do góry

On Sun, 23 May 2010 22:55:16 +0100, Peter May <p...@o...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");

do góry

W dniu 2010-05-25 23:21, porneL pisze:
> On Sun, 23 May 2010 22:55:16 +0100, Peter May <p...@o...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

do góry

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.

do góry

On Fri, 28 May 2010 21:38:07 +0100, Colin <c...@c...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");

do góry