2015-02-13 14 views
10

Nasza firma planowała użyć Knockoutjs, ale znalazłem this link omawiające kwestie bezpieczeństwa w KnockoutJS. Mówią, że ludzie mogą łatwo wstrzyknąć szkodliwy kod w atrybut wiążący dane.Jak chronić się przed atakami iniekcyjnymi podczas korzystania z KnockoutJS?

Na przykład:

<script src="http://knockoutjs.com/downloads/knockout-2.3.0.js"></script> 
<div data-bind="x:alert(1)" /> 
<script> 
    ko.applyBindings(); 
</script> 

nie mam bardzo dobrą wiedzę na temat ataków XSS, a ja nie wiem, jak wiele sposobów ludzie mogą wstrzyknąć złośliwy kod na stronie internetowej.

  1. ktoś może mi powiedzieć, kiedy strona jest wyświetlana na komputerze klienckim, a następnie, jak ludzie mogą wstrzyknąć ten <div data-bind="x:alert(1)" /> tylko po to żeby to działało? Czy ktoś może mi powiedzieć, jak hakerzy mogą wstrzykiwać to na stronie otwartej w przeglądarce?

  2. Czy ktoś może mi powiedzieć, jakie inne problemy związane z zabezpieczeniami są dla knockoutjs?

Jeśli nie jest bardzo bezpieczny, nie będę go używać.

Dostałam też linki byli trochę o tym, jak lepiej zabezpieczyć knockoutjs:

Czy ktoś zdaje sobie sprawę, jak uzyskać knockoutjs pełni zabezpieczona? Ponieważ widziałem samouczek dla KnockoutJS i czułem, że krzywa uczenia się nie jest wysoka.

+0

Czy istnieje lista narzędzi, które sprawdzają adres URL witryny przez adres URL, aby sprawdzić zagrożenie i lukę w zabezpieczeniach, a na końcu pokaż szczegóły w każdym adresie URL i problemie bezpieczeństwa. daj mi znać. dzięki – Mou

+1

Miałem tylko czas na pobieżne badanie witryny, z którą się łączyłeś i prezentacji Slideshare, ale z tego co rozumiem, ich krytyka jest taka, że ​​** jeśli ** atakujący zdoła wstawić na przykład atrybuty związania danych z nią wybór, Knockout i inne struktury JSMVC oferują szerszą niż potrzebną powierzchnię ataku. Nie określa, w jaki sposób osoba atakująca ma wstrzyknąć kod, lub, że w jakiś sposób korzysta z funkcji Knockout. Złota zasada, obowiązująca tutaj jak wszędzie: * nie ufaj danym dostarczonym przez użytkownika *. Np. Nigdy nie umieszczaj rzeczy, które otrzymałeś od użytkownika, na wiązaniach html. – janfoeh

+0

[Otwarty projekt bezpieczeństwa aplikacji internetowych] (https: //www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_ \ (XSS \)) jest dobrym miejscem do zapoznania się z XSS i innymi zagrożeniami. – janfoeh

Odpowiedz

5

"Zabezpieczenie nokautu" nie jest sposobem zapobiegania XSS.

trzeba zarządzać swoją ekspozycję XSS w pierwszej kolejności, niezależnie od tego jak są wiążące dla danych elementów w aplikacji i że zaczyna się od zabezpieczania stronę, która ma wiążącego w pierwszej kolejności nokaut:

  • Sprawdź poprawność danych wejściowych, które będą miały wpływ na powrót tej konkretnej strony internetowej elementu listy

  • nie pozwalają użytkownikom na renderowanie wyjście HTML świadczone przez użytkowników bez odkażania najpierw

  • Nie zezwalaj niezaufanym stronom trzecim na dostarczanie referencji do skryptów lub dołączanie linków od podmiotów trzecich, którym nie jesteś zaufany .

Pełna lista sposobów zapobiegania XSS jest tutaj:

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Można zauważyć, że „nie używając nokaut” nie znajduje się na żadnej z tych list i że większość problemów związanych jest z zarządzaniem danymi wprowadzanymi przez użytkownika i jego skutkami w kodzie skryptu. To samo dotyczy tego, w jaki sposób dane wejściowe użytkownika kończą się wiązaniem nokautu.

Zarządzanie ekspozycją nokautu za pomocą bezpiecznego mechanizmu wiążącego, który połączono powyżej, zmniejszy potencjalną powierzchnię ataku.

Ale jeśli masz złośliwy kawałek html zwrócony przez twój serwer lub linkowany na twojej stronie, niezależnie od tego, czy masz nokaut, czy nie, masz problem z XSS.

Powiązane problemy