HTML-Codierung auf die Schicht Geschäft Hinzufügen

Question

Wenn eine Benutzereingabe zu einer Webseite hinzufügen, sollten sie (es sei denn, es HTML ist natürlich :) XSS-Angriffe codiert werden usw., um zu verhindern .. wie folgt aus:

litForename.Text = HttpUtility.HtmlEncode(MyUser.Forename); 

I Ich stelle eine Vorlage zusammen, um meine Business-Logik-Ebene zu generieren, und ich denke daran, sie zu verwenden, um die ganze Codierung durchzuführen, sobald die Daten aus der Datenbank kommen, bevor sie den UI-Code erreichen. Dies stellt sicher, dass alles codiert ist, was sein sollte (ich würde natürlich die Spalten ausschließen, die Xhtml/Xml-Zeichenfolgen enthalten). Eine Überlastung der Datenzugriffsmethoden wird das Abrufen von Daten ohne Codierung erlauben (so es bearbeitet werden kann):

// Get a 'User' entity with all the string fields HTML encoded 
BLL.Users.GetById(int userId) 

// Get a 'User' entity with optional HTML encoding 
BLL.Users.GetById(int userId, bool useHtmlEncoding) 

Ist dies ein Ansatz, dass jeder andere Anwendungen, oder es eine dumme Idee ist? Was sind die Vor- und Nachteile?

Danke.

Answer 1

Es kann Randfälle geben, wo dies sinnvoll ist, aber generell würde ich davon abraten. Ihre Geschäftslogikschicht sollte nur mit Geschäftslogik und Geschäftslogik umgehen.

Ebenso sollten Ihre Controller (unter der Annahme von ASP.NET MVC) mit Werten arbeiten, die im Zusammenhang mit Ihrer Geschäftsdomäne sinnvoll sind, anstatt bereits in Erwartung eines bestimmten UI-Typs geänderte Werte.

Ihre UI-Schicht ist die einzige Schicht, die wissen und sich darum kümmern sollte, um welche Art von UI es sich handelt. Momentan scheint Ihre einzige Art von Benutzeroberfläche HTML-basiert zu sein, aber das könnte sich ändern.

Answer 2

Das Problem mit HtmlEncode auf Daten, die in der Datenbank gespeichert wird, ist, dass Sie dann mit Dingen wie & und " in Ihren Daten beschäftigen müssen. Zum Beispiel wird "Tom O'Brien" in der Datenbank als "Tom O " Brien" gespeichert. Ein SELECT oder UPDATE zu machen wird schwierig.

Ich denke, Sie werden es besser machen, indem Sie nur HtmlEncode für die Anzeige von Text in der Benutzeroberfläche verwenden.

Answer 3

Ich stimme den anderen Postern zu, dass Datenkonvertierung auf Ansichtsebene in die Ansichtserzeugung gehört. Sie können mit XML-basierten Ansichten beginnen (z. B. XHTML, VoiceXML für Sprachsuche, XML für Webdienste). Was passiert jedoch, wenn Sie JSON-Ansichten zur Unterstützung von AJAX-Interaktionen benötigen? JavaScript-Literale von JSON verwenden einen anderen Escape-Mechanismus als XML.

Sie haben auch Fälle, in denen eine logische Tier-Methode eine andere für einen Zweck aufrufen muss, der nicht mit der Generierung von Views zusammenhängt. Möglicherweise muss die aufrufende Methode eine Massendatentransformation anwenden, die eine andere Datenbanktabelle auffüllt. Die aufrufende Methode müsste in diesem Fall die XML-Escapes rückgängig machen.

Answer 4

Ihre Geschäftslogik sollte wirklich nicht über Ihre Präsentation wissen. Unabhängig davon, ob Sie ein Web, Windows oder eine andere Art von Benutzeroberfläche bereitstellen, sollten Sie diese Details nicht in Ihrer Geschäftslogik haben.

Haben Sie in Betracht gezogen, dass Personen, die Ihre Business-Schicht verwenden, versuchen könnten, die Daten erneut zu codieren? Das könnte dazu führen, dass die Dinge wirklich unordentlich aussehen.

Answer 5

Lernen Sie die Lektionen von PHP's magic_quotes_gpc Feature: solche Codierung wird zweifellos nur Dinge mehr verwirren, verursachen Sie zu entfremden, wenn Sie nicht sollten, vergessen zu entkommen, wenn Sie sollten, und im Allgemeinen ein Schmerz sein. Kodieren Sie Ihre Daten erst, wenn sie gesendet werden sollen, wo sie hingehört, sei es in der Datenbank, im Web oder anderswo.