Co robisz, gdy klient wymaga edycji tekstu sformatowanego w swojej witrynie?

Jak wszyscy wiemy, ataki XSS są niebezpieczne i bardzo łatwe do odparcia . Różne frameworki ułatwiają kodowanie HTML, podobnie jak ASP.NET MVC:

<%= Html.Encode("string"); %>

Ale co się stanie, gdy klient wymaga, aby mógł przesyłać swoje treści bezpośrednio z dokumentu Microsoft Word?

Oto scenariusz: ludzie mogą kopiować i wklejać treść ze słowa Microsoft do edytora WYSIWYG (w tym przypadku tinyMCE ), a następnie informacje te są publikowane na stronie internetowej.

Witryna jest publiczna, ale tylko członkowie tej organizacji będą mieli dostęp do publikowania informacji na stronie internetowej.

Jak bezpiecznie obsługiwać te wymagania? Obecnie nie jest sprawdzane, co publikuje klient (ponieważ tylko „zaufani” użytkownicy mogą publikować), ale nie jestem z tego szczególnie zadowolony i chciałbym go jeszcze bardziej zablokować w przypadku zhakowania konta.

Jedyną znaną mi konceptualną metodą, która spełnia te wymagania, jest umieszczenie tagów HTML na białej liście i przepuszczanie ich . Czy jest inny sposób? Jeśli nie, jaki jest bezpieczny sposób, aby umożliwić użytkownikowi przechowywanie danych wejściowych w bazie danych w dowolnej formie, ale tylko wyświetlanie ich poprawnie zakodowanych i pozbawionych złych znaczników?

Powiązane pytanie

Zapobieganie skryptom krzyżowym (XSS)

Najłatwiejszym sposobem (dla ciebie jako programisty) jest prawdopodobnie zaimplementowanie jednej z wielu odmian Markdown , na przykład Markdown.NET lub, jeszcze lepiej (imho), edytora wmd .

Wówczas użytkownicy mogliby wkleić prosty HTML, ale nic niebezpiecznego, i mogliby przeglądać wprowadzone dane i wyprostować wszelkie skrupuły nawet przed opublikowaniem ...

Biała lista jest rzeczywiście najlepszym sposobem na zapobieganie atakom XSS, gdy pozwala się użytkownikom na wprowadzanie HTML, bezpośrednio lub przy użyciu edytora tekstu sformatowanego.

O twoich pozostałych pytaniach:

Czy istnieje edytor WYSIWYG, który ma możliwość dodania do białej listy w locie?

Nie sądzę, żeby to mogło zadziałać. Potrzebujesz do tego kodu po stronie serwera, a RTE działa na kliencie.

TinyMCE filtruje tagi, jeśli chcesz, ale ponieważ odbywa się to w przeglądarce, nie możesz mu ufać. Zobacz Extended_valid_elements . TinyMCE (Moxie) sugeruje również białą listę, patrz tutaj .

Czy powinienem się tym martwić, ponieważ będzie to dotyczyło tylko „prywatnego wysyłania”

Zawsze powinieneś filtrować HTML, chyba że istnieją szczególne powody, aby tego nie robić (bardzo rzadko). Niektóre powody: a) funkcjonalność, która jest dziś dla użytkowników wewnętrznych, może dla społeczeństwa jutro, b) nieuprawniony dostęp będzie miał mniejszy wpływ

jest najlepszym sposobem, aby pozwolić im przechowywać go w bazie danych w dowolnej formie, ale wyświetlać tylko odpowiednio zakodowane i pozbawione złych tagów?

Tak wolę. Z różnych powodów nie lubię zmieniać danych wejściowych użytkownika przed wstawieniem do bazy danych.

Robię to samo. Korzystam z TinyMCE i pozwalam na wklejanie z dokumentów Word. Tylko niektóre osoby, które utrzymują witrynę, mogą to zrobić za pośrednictwem obszaru administracyjnego. Jest to zabezpieczone przez członkostwo ASP.Net. Po prostu wykonuję HTML.Encode, gdy zostanie wysłany na stronę publiczną.

Możesz użyć poniższego kodu, jeśli chcesz, zanim zostanie on umieszczony w bazie danych, ale nie jesteś pewien, co na niego wpłynie. Może być konieczne użycie białej listy.

 /// <summary>
    /// Strip HTML
    /// </summary>
    /// <param name="str"></param>
    /// <returns></returns>
    public static string StripHTML(string str)
    {
        //Strips the HTML tags from strHTML 
        System.Text.RegularExpressions.Regex objRegExp = new System.Text.RegularExpressions.Regex("<(.|\n)+?>");

        // Replace all tags with a space, otherwise words either side 
        // of a tag might be concatenated 
        string strOutput = objRegExp.Replace(str, " ");

        // Replace all < and > with < and > 
        strOutput = strOutput.Replace("<", "<");
        strOutput = strOutput.Replace(">", ">");

        return strOutput;
    }

Jedną z opcji może być kontrola edycji HTML dla platformy .NET (którą napisałem).

Jest to edytor HTML WYSIWYM dla platformy .NET, który obsługuje tylko podzbiór elementów HTML , z wyłączeniem <script>elementów: w ten sposób działa jak biała lista.

Jeśli jest to do użytku wewnętrznego (tj. Strona intranetowa), wówczas kontrolę można osadzić na stronie internetowej .

Nie zintegrowałem obsługi wklejania z Worda, ale mam komponent, który jest krokiem w tym kierunku: konwerter Doc na HTML ; więc mam bloki konstrukcyjne, których można użyć w ASP.NET do konwersji dokumentu na HTML, wyświetlania HTML w edytorze itp.

Mój IMHO ufaj swoim użytkownikom, dopóki nie upublicznisz się.

Cóż, nie ma niezawodnego sposobu na zaspokojenie twoich potrzeb. Na przykład jakikolwiek edytor WYSIWYG nie chroni formularza wstawiając obrazy z adresami URL (pośredni ślad użytkowania, nielegalna treść) lub tekstem (nielegalny tekst, błędnie napisany tekst, pominięty tekst).

Moim punktem widzenia jest to, że jeśli możesz zaufać swoim użytkownikom, po prostu zezwól na wszystko, po prostu ostrzeż użytkowników, jeśli istnieją WIEDZIEĆ o niebezpiecznych znacznikach (aby uchronić ich przed błędami).

Jeśli nie ufasz, użyj specjalnego rodzaju znaczników (np. Markdown).

W moim projekcie używamy specjalnych typów dla potencjalnie niebezpiecznych treści oraz specjalnych metod renderowania i akceptowania takich treści. Ten kod ma wysoką ocenę w naszym modelu wątków i przywiązanie do niego jest bardzo wysokie (na przykład każda zmiana powinna zostać przejrzana przez dwóch niezależnych programistów, mamy kompleksowy zestaw testów i tak dalej).