2011-07-15 8 views
9

Pracuję nad aplikacją webapp do nauczania koncepcji programowania. Strony internetowe zawierają trochę tekstu o koncepcji programowania, a następnie pozwalają użytkownikowi wpisać kod javascript w oknie edytora tekstu, aby spróbować odpowiedzieć na problem programowania. Gdy użytkownik kliknie przycisk "prześlij", analizuję tekst, który wpisał, aby sprawdzić, czy rozwiązał problem. Na przykład, proszę je "napisać funkcję o nazwie f, która dodaje trzy do jej argumentu".Jak bezpiecznie "eval" kod użytkownika na stronie internetowej?

Oto co robię analizować tekst użytkownika:

  1. Run JSLint sprawie tekstu z rygorystycznymi ustawieniami, szczególnie bez zakładając funkcje przeglądarki lub konsoli.
  2. Jeśli wystąpią jakiekolwiek błędy, pokaż błędy i zatrzymaj się.
  3. eval(usertext);
  4. Warunki przejścia przez przelot, eval(condition). Przykładowy warunek to "f(1)===4". Warunki pochodzą z zaufanego źródła.
  5. Pokaż warunki przejścia/niepowodzenia.

Moje pytania: czy to wystarczająco dobre, aby zapobiec problemom bezpieczeństwa? Co jeszcze mogę zrobić, aby być paranoikiem? Czy istnieje lepszy sposób robienia tego, co chcę?

Jeśli jest to istotne, moja aplikacja działa w Google App Engine z backendem Pythona, używa JQuery, ma indywidualne konta użytkowników.

+0

Zastanawiam się, czy jsfiddle ma jakieś źródło/notatki dostępne ... Jestem pewien, że w pewnym momencie sprowadza się on do witryny, która nie jest podatna na XSS lub podobne.(XSS może * pozwolić komuś innemu * podać link do kodu eval'ed na wspomnianej stronie, która może wtedy "działać jako" użytkownik, który faktycznie przeglądał link.) –

+0

Muszę powiedzieć, kiedy używam JSLint do przeskanowania mojego JS dla problemy przed kompresją Próbuję wyłączyć każdą funkcję, która może reprezentować preferencje autora, a nie kwestię kodu, wtedy pomijam 90% tego, co jest napisane i szukam brakujących średników i tym podobnych. Gdybym był tobą, zastanawiałbym się, ile użytkownicy będą lubili czytać "błędy" znalezione przez JSLint. – tomfumb

+0

To dobra uwaga, dodam opcję wyłączenia czeków "stylistycznych". Ale chcę, aby domyślne było ścisłe, częścią projektu jest nauczenie czystego programowania w javascript. –

Odpowiedz

11

Z tego co wiem, czy oceniasz dane wejściowe użytkownika tylko dla nich, nie stanowi to problemu z zabezpieczeniami. Tylko jeśli ich dane wejściowe są eval'd dla innych użytkowników masz problem.

Ewaluacja danych wejściowych użytkownika nie jest gorsza od źródła ich wyświetlania, oglądania nagłówków HTTP, używania Firebug do sprawdzania obiektów JavaScript itp. Mają już dostęp do wszystkiego.

Biorąc to pod uwagę, jeśli trzeba zrobić, aby zabezpieczyć swój kod, sprawdź Google Caja http://code.google.com/p/google-caja/

+0

To dobra uwaga. Jeśli masz Firebuga, możesz ocenić wszystko, co chcesz. –

+1

Zgadzam się tutaj. Nie jest problemem związanym z bezpieczeństwem, aby użytkownik mógł manipulować własną przeglądarką. Istnieje już wiele sposobów, aby to zrobić (Firebug, GreaseMonkey, skopiuj źródło i edytuj je, itp ...). Staje się to problemem związanym z bezpieczeństwem tylko wtedy, gdy inny użytkownik może kiedykolwiek wykonać niezaufany kod w środowisku należącym do innego użytkownika niż ten, który go utworzył, nie wiedząc, co może zrobić. – jfriend00

+0

To naprawdę bardzo dobry punkt. +1 – AlienWebguy

2

To podchwytliwe pytanie. Nie ma bezpiecznego sposobu na wpisanie kodu użytkownika w Twojej witrynie na numer eval().

+0

Tak, ale rozważ jsfiddle - jak można to zrobić "przy akceptowalnych środkach"? –

1

To nie może być zrobione. Przeglądarki nie oferują interfejsu API do stron internetowych w celu ograniczenia tego, jaki kod może zostać wykonany w danym kontekście.

Jednak to nie ma znaczenia. Jeśli nie używasz żadnych plików cookie na swojej stronie internetowej, wtedy wykonanie dowolnej JavaScript może nie stanowić problemu. W końcu, jeśli nie ma koncepcji uwierzytelniania, to nie ma problemu z wnioskami kowalskimi. Dodatkowo, jeśli możesz potwierdzić, że użytkownik oznaczał do wykonania skryptu, który wysłał, to powinieneś również być chroniony przed atakującymi, np. Jeśli uruchomisz tylko skrypt wpisany na stronie i nigdy skrypt przesłany przez GET lub POST danych lub jeśli dołączasz do nich jakiś unikalny token, aby potwierdzić, że żądanie pochodzi z Twojej witryny.

Mimo to, odpowiedzią na pytanie o rdzeń jest to, że prawie nie można tego zrobić, i że dane wejściowe użytkownika nigdy nie mogą być zaufane. Przepraszam:/

+0

Istnieje koncepcja uwierzytelniania, są konta użytkowników Google. Nie wiem, w jaki sposób są one zaimplementowane w GAE, ale domyślam się, że pliki cookie przechowują klucz wspólny sesji lub coś takiego. Czy możesz wyjaśnić nieco więcej na temat rozróżniania między wpisanymi skryptami a żądaniami GET POST? Jak mogę odróżnić? –

+0

@Nathan: jeśli użytkownik wpisze skrypt na stronie, można go bezpiecznie uruchomić, ponieważ wiemy, że użytkownik chciał go przesłać. Jeśli jednak kod pochodzi z danych GET lub POST, złośliwy użytkownik może nakłonić innego użytkownika do wysłania tego żądania i uruchomienia tego skryptu. (Dla GET jest to łatwe z linkiem. W przypadku POST formularz automatycznego przesyłania nie jest o wiele trudniejszy.) Dlatego te prośby nie powinny być dozwolone, chyba że masz pewność, że pochodzą z Twojej witryny, co oznacza, że ​​formularze Twojej witryny muszą zawierać dane, których nie może mieć złośliwy użytkownik. Sprawdź fałszerstwo żądań między witrynami i nadaj użytkownikom tajny token. – Matchu

Powiązane problemy