Sicherheitsrahmen: Eingabeüberprüfung | Risikominderung
Deaktivieren der XSLT-Skripterstellung für alle Transformationen, die nicht vertrauenswürdige Stylesheets verwenden
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | XSLT-Sicherheit, XsltSettings.EnableScript-Eigenschaft |
| Schritte | XSLT unterstützt die Skripterstellung in Stylesheets mit dem <msxml:script>-Element. Dadurch können benutzerdefinierte Funktionen in XSLT-Transformationen verwendet werden. Das Skript wird im Kontext des Prozesses, der die Transformation durchführt, ausgeführt. Das XSLT-Skript muss in einer nicht vertrauenswürdigen Umgebung deaktiviert werden, um die Ausführung von nicht vertrauenswürdigem Code zu verhindern. Bei Verwendung von .NET: Die XSLT-Skriptverarbeitung ist standardmäßig deaktiviert; Sie müssen jedoch sicherstellen, dass sie nicht über die XsltSettings.EnableScript-Eigenschaft explizit aktiviert wurde. |
Beispiel
XsltSettings settings = new XsltSettings();
settings.EnableScript = true; // WRONG: THIS SHOULD BE SET TO false
Beispiel
Wenn Sie MSXML 6.0 verwenden, ist die XSLT-Skriptverarbeitung standardmäßig deaktiviert; Sie müssen jedoch sicherstellen, dass sie nicht über die XML DOM-Objekteigenschaft „AllowXsltScript“ explizit aktiviert wurde.
doc.setProperty("AllowXsltScript", true); // WRONG: THIS SHOULD BE SET TO false
Beispiel
Wenn Sie MSXML 5 oder niedriger verwenden, ist die XSLT-Skriptverarbeitung standardmäßig aktiviert, und Sie müssen Sie explizit deaktivieren. Legen Sie für die XML-DOM-Objekteigenschaft AllowXsltScript „false“ fest.
doc.setProperty("AllowXsltScript", false); // CORRECT. Setting to false disables XSLT scripting.
Sicherstellen, dass jede Seite, die von Benutzern steuerbare Inhalte enthalten könnte, von der automatischen MIME-Ermittlung abgemeldet wird
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | IE8-Sicherheit Teil V – Umfassender Schutz |
| Schritte | Für jede Seite, die von Benutzern steuerbare Inhalte enthalten könnte, müssen Sie den HTTP-Header Jeder von einem Webserver übermittelten Datei ist ein MIME-Typ (auch Inhaltstyp genannt) zugeordnet, der die Art des Inhalts beschreibt (d.h. Bild, Text, Anwendung usw.) Der Header „X-Content-Type-Options“ ist ein HTTP-Header, mit dem Entwickler festlegen, dass für ihre Inhalte keine MIME-Ermittlung erfolgen soll. Dieser Header dient zur Minderung von MIME-Ermittlungsangriffen. Dieser Header wurde in Internet Explorer 8 (IE8) hinzugefügt. Nur Benutzer von Internet Explorer 8 (IE8) können von „X-Content-Type-Options“ profitieren. Vorherige Versionen von Internet Explorer unterstützen den X-Content-Type-Options-Header derzeit nicht. Internet Explorer 8 (und höher) ist der einzige Browser, in dem ein Feature zum Deaktivieren der MIME-Ermittlung implementiert werden kann. Wenn andere gängige Browser (Firefox, Safari, Chrome) ähnliche Funktionen implementieren, wird diese Empfehlung um eine MDX-Syntax für diese Browser ergänzt. |
Beispiel
Um den erforderlichen Header global für alle Seiten in der Anwendung zu aktivieren, können Sie einen der folgenden Schritte ausführen:
- Den Header der Datei „web.config“ hinzufügen, wenn die Anwendung von Internet Information Services (IIS) 7 gehostet wird
<system.webServer>
<httpProtocol>
<customHeaders>
<add name=""X-Content-Type-Options"" value=""nosniff""/>
</customHeaders>
</httpProtocol>
</system.webServer>
- Den Header über die globale Anforderung „Application_BeginRequest“ hinzufügen
void Application_BeginRequest(object sender, EventArgs e)
{
this.Response.Headers[""X-Content-Type-Options""] = ""nosniff"";
}
- Implementieren des benutzerdefinierten HTTP-Moduls
public class XContentTypeOptionsModule : IHttpModule
{
#region IHttpModule Members
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.PreSendRequestHeaders += newEventHandler(context_PreSendRequestHeaders);
}
#endregion
void context_PreSendRequestHeaders(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
if (application == null)
return;
if (application.Response.Headers[""X-Content-Type-Options ""] != null)
return;
application.Response.Headers.Add(""X-Content-Type-Options "", ""nosniff"");
}
}
- Sie können den erforderlichen Header nur für bestimmte Seiten aktivieren, indem sie ihn einzelnen Antworten hinzufügen:
this.Response.Headers[""X-Content-Type-Options""] = ""nosniff"";
Absichern oder Deaktivieren der XML-Entitätsauflösung
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | XML-Entitätserweiterung, XML-Dienstverweigerungsangriffe und Verteidigungsmaßnahmen, MSXML Sicherheitsübersicht, Bewährte Methoden für das Sichern von MSXML-Code, NSXMLParserDelegate-Protokollreferenz, Auflösen von externen Referenzen |
| Schritte | Auch wenn sie nicht häufig verwendet wird, ist eine XML-Funktion vorhanden, die dem XML-Parser das Erweitern von Makroentitäten um im Dokument selbst oder aus externen Quellen definierte Werte ermöglicht. Beispielsweise kann das Dokument eine Entität "Firmenname" mit dem Wert "Microsoft" definieren, sodass der Text "&companyname;" im Dokument automatisch durch den Text "Microsoft" ersetzt wird. Das Dokument könnte auch eine Entität „MSFTStock“ definieren, das zum Abrufen des aktuellen Werts der Microsoft-Aktie auf einen externen Webdienst verweist. Jedes Mal, wenn "&MSFTStock;" im Dokument angezeigt wird, wird es automatisch durch den aktuellen Aktienkurs ersetzt. Diese Funktion kann jedoch durch Denial of Service (DoS)-Bedingungen missbraucht werden. Ein Angreifer kann mehrere Entitäten schachteln, um eine exponentielle XML-Expansionsbombe zu erstellen, die den gesamten verfügbaren Arbeitsspeicher im System beansprucht. Alternativ kann er einen externen Verweis erstellen, der eine unendliche Datenmenge streamt oder den Thread einfach aufhängt. Daher müssen alle Teams die interne und/oder externe XML-Entitätsauflösung deaktivieren, wenn ihre Anwendung sie nicht verwendet, oder manuell die Menge an Arbeitsspeicher und Zeit begrenzen, die die Anwendung für die Auflösung von Entitäten nutzen darf, wenn dies absolut notwendig ist. Wenn Ihre Anwendung die Entitätsauflösung nicht benötigt, deaktivieren Sie sie. |
Beispiel
Für .NET Framework-Code können Sie die folgenden Ansätze verwenden:
XmlTextReader reader = new XmlTextReader(stream);
reader.ProhibitDtd = true;
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = true;
XmlReader reader = XmlReader.Create(stream, settings);
// for .NET 4
XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit;
XmlReader reader = XmlReader.Create(stream, settings);
Beachten Sie, dass der Wert von ProhibitDtd in XmlReaderSettings „true“, aber in XmlTextReader „false“ lautet. Wenn Sie „XmlReaderSettings“ verwenden, müssen Sie „ProhibitDtd“ nicht explizit auf „true“ festlegen, aber aus Sicherheitsgründen raten wir dazu. Beachten Sie zudem, dass die XmlDocument-Klasse die Entitätsauflösung standardmäßig zulässt.
Beispiel
Verwenden Sie zum Deaktivieren der Entitätsauflösung für XmlDocuments die XmlDocument.Load(XmlReader)-Überladung der Load-Methode und legen Sie die entsprechenden Eigenschaften im XmlReader-Argument fest, um die Auflösung wie im folgenden Code zu deaktivieren:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = true;
XmlReader reader = XmlReader.Create(stream, settings);
XmlDocument doc = new XmlDocument();
doc.Load(reader);
Beispiel
Wenn Sie die Entitätsauflösung für Ihre Anwendung nicht deaktivieren können, legen Sie für die XmlReaderSettings.MaxCharactersFromEntities-Eigenschaft einen geeigneten Wert gemäß den Anforderungen Ihrer Anwendung fest. Dadurch wird die Auswirkung von potenziellen exponentiellen DoS-Angriffen eingeschränkt. Der folgende Code enthält ein Beispiel für diesen Ansatz:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = false;
settings.MaxCharactersFromEntities = 1000;
XmlReader reader = XmlReader.Create(stream, settings);
Beispiel
Wenn Sie Inline-Entitäten, aber keine externen Entitäten auflösen müssen, legen Sie für die XmlReaderSettings.XmlResolver-Eigenschaft den Wert „null“ fest. Beispiel:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = false;
settings.MaxCharactersFromEntities = 1000;
settings.XmlResolver = null;
XmlReader reader = XmlReader.Create(stream, settings);
Beachten Sie, dass in MSXML6 für „ProhibitDTD“ standardmäßig „true“ (deaktiviert die DTD-Verarbeitung) festgelegt ist. Für Apple OSX/iOS-Code können Sie zwei XML-Parser verwenden: NSXMLParser und libXML2.
Anwendungen, die „http.sys“ verwenden, überprüfen die Kanonisierungstransformation
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | – |
| Schritte | Jede Anwendung, die „http.sys“ verwendet, sollten diese Richtlinien befolgen:
|
Sicherstellen, dass entsprechende Kontrolle gelten, wenn Dateien vom Benutzer akzeptiert werden
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | Unbeschränkter Dateiupload, Dateisignaturtabelle |
| Schritte | Hochgeladene Dateien stellen ein erhebliches Risiko für Anwendungen dar. Bei vielen Angriffen besteht der erste Schritt daran, Code des Systems abzugreifen, das angegriffen werden soll. Anschließend muss der Angreifer nur eine Gelegenheit finden, den Code auszuführen. Ein Dateiupload hilft dem Angreifer beim ersten Schritt. Die Folgen des uneingeschränkten Dateiuploads reichen von der Übernahme des vollständigen Systems, Überlastung des Dateisystems oder der Datenbank über die Weiterleitung der Angriffe auf Back-End-Systeme bis zur einfachen Verunstaltung. Das Ausmaß hängt davon ab, was die Anwendung mit der hochgeladenen Datei macht und insbesondere, wo sie gespeichert ist. Die Validierung des Dateiuploads auf dem Server fehlt. Folgende Sicherheitsmaßnahmen sollte für Dateiuploads implementiert werden:
|
Beispiel
Informationen zur Überprüfung der Dateiformatsignatur finden Sie in der folgenden Klasse:
private static Dictionary<string, List<byte[]>> fileSignature = new Dictionary<string, List<byte[]>>
{
{ ".DOC", new List<byte[]> { new byte[] { 0xD0, 0xCF, 0x11, 0xE0, 0xA1, 0xB1, 0x1A, 0xE1 } } },
{ ".DOCX", new List<byte[]> { new byte[] { 0x50, 0x4B, 0x03, 0x04 } } },
{ ".PDF", new List<byte[]> { new byte[] { 0x25, 0x50, 0x44, 0x46 } } },
{ ".ZIP", new List<byte[]>
{
new byte[] { 0x50, 0x4B, 0x03, 0x04 },
new byte[] { 0x50, 0x4B, 0x4C, 0x49, 0x54, 0x55 },
new byte[] { 0x50, 0x4B, 0x53, 0x70, 0x58 },
new byte[] { 0x50, 0x4B, 0x05, 0x06 },
new byte[] { 0x50, 0x4B, 0x07, 0x08 },
new byte[] { 0x57, 0x69, 0x6E, 0x5A, 0x69, 0x70 }
}
},
{ ".PNG", new List<byte[]> { new byte[] { 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A } } },
{ ".JPG", new List<byte[]>
{
new byte[] { 0xFF, 0xD8, 0xFF, 0xE0 },
new byte[] { 0xFF, 0xD8, 0xFF, 0xE1 },
new byte[] { 0xFF, 0xD8, 0xFF, 0xE8 }
}
},
{ ".JPEG", new List<byte[]>
{
new byte[] { 0xFF, 0xD8, 0xFF, 0xE0 },
new byte[] { 0xFF, 0xD8, 0xFF, 0xE2 },
new byte[] { 0xFF, 0xD8, 0xFF, 0xE3 }
}
},
{ ".XLS", new List<byte[]>
{
new byte[] { 0xD0, 0xCF, 0x11, 0xE0, 0xA1, 0xB1, 0x1A, 0xE1 },
new byte[] { 0x09, 0x08, 0x10, 0x00, 0x00, 0x06, 0x05, 0x00 },
new byte[] { 0xFD, 0xFF, 0xFF, 0xFF }
}
},
{ ".XLSX", new List<byte[]> { new byte[] { 0x50, 0x4B, 0x03, 0x04 } } },
{ ".GIF", new List<byte[]> { new byte[] { 0x47, 0x49, 0x46, 0x38 } } }
};
public static bool IsValidFileExtension(string fileName, byte[] fileData, byte[] allowedChars)
{
if (string.IsNullOrEmpty(fileName) || fileData == null || fileData.Length == 0)
{
return false;
}
bool flag = false;
string ext = Path.GetExtension(fileName);
if (string.IsNullOrEmpty(ext))
{
return false;
}
ext = ext.ToUpperInvariant();
if (ext.Equals(".TXT") || ext.Equals(".CSV") || ext.Equals(".PRN"))
{
foreach (byte b in fileData)
{
if (b > 0x7F)
{
if (allowedChars != null)
{
if (!allowedChars.Contains(b))
{
return false;
}
}
else
{
return false;
}
}
}
return true;
}
if (!fileSignature.ContainsKey(ext))
{
return true;
}
List<byte[]> sig = fileSignature[ext];
foreach (byte[] b in sig)
{
var curFileSig = new byte[b.Length];
Array.Copy(fileData, curFileSig, b.Length);
if (curFileSig.SequenceEqual(b))
{
flag = true;
break;
}
}
return flag;
}
Sicherstellen, dass typsichere Parameter für den Datenzugriff in Webanwendungen verwendet werden
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | – |
| Schritte | Wenn Sie die Parametersammlung verwenden, behandelt SQL die Eingabe als literalen statt ausführbaren Code. Die Parametersammlung kann verwendet werden, um Typ- und Längenbeschränkungen bei Eingabedaten zu erzwingen. Bei Werten außerhalb des Bereichs wird eine Ausnahme ausgelöst. Wenn keine typsicheren SQL-Parameter verwendet werden, können Angreifer möglicherweise Einschleusungsangriffe ausführen, die in die ungefilterte Eingabe eingebettet sind. Verwenden Sie beim Erstellen der SQL-Abfragen typsichere Parameter, um mögliche SQL-Einschleusungsangriffe zu verhindern, die bei ungefilterten Eingaben auftreten können. Sie können typsichere Parameter mit gespeicherten Prozeduren und dynamischen SQL-Anweisungen verwenden. Parameter werden von der Datenbank als literale Werte und nicht als ausführbarer Code behandelt. Parameter werden auch auf Typ und Länge überprüft. |
Beispiel
Der folgende Code zeigt die Verwendung typsicherer Parameter in der SqlParameterCollection beim Aufrufen einer gespeicherten Prozedur.
using System.Data;
using System.Data.SqlClient;
using (SqlConnection connection = new SqlConnection(connectionString))
{
DataSet userDataset = new DataSet();
SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure", connection);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;
myCommand.Fill(userDataset);
}
Im vorigen Codebeispiel darf der Eingabewert darf nicht mehr als 11 Zeichen umfassen. Wenn der Typ oder die Länger der Daten nicht dem vom Parameter definierten Wert entspricht, wird von die Klasse „SqlParameter“ eine Ausnahme ausgelöst.
Verwenden separater Modellbindungsklassen oder Bindungsfilterlisten, um Sicherheitslücken bei der MVC-Massenzuweisung vorzubeugen
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | MVC5, MVC6 |
| Attribute | – |
| Referenzen | Metadatenattribute, Sicherheitslücken bei öffentlichen Schlüssel und Gegenmaßnahmen, Vollständige Anleitung zur Massenzuweisung in ASP.NET MVC, Erste Schritte in EF mit MVC |
| Schritte |
|
Codieren nicht vertrauenswürdiger Webausgabe vor dem Rendering
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein, Web Forms, MVC5, MVC6 |
| Attribute | – |
| Referenzen | Verhindern von Cross-Site-Scripting in ASP.NET, Cross-Site-Scripting, Spickzettel zum Verhindern von XSS (Cross-Site-Scripting) |
| Schritte | Cross-Site-Scripting (Abkürzung: XSS) ist ein Angriffsvektor für Onlinedienste oder beliebige Anwendungen/Komponenten, die Eingabe aus dem Web verwenden. XSS-Sicherheitsrisiken können einem Angreifer das Ausführen von Skripts auf dem Computer eines anderen Benutzers über eine gefährdete Webanwendung ermöglichen. Schädliche Skripts können verwendet werden, um Cookies zu stehlen oder den Computer des Opfers über JavaScript zu manipulieren. XSS wird durch die Überprüfung von Benutzereingaben, deren Form und Codierung vor dem Rendern auf einer Webseite verhindert. Die Überprüfung von Benutzereingaben und Ausgabecodierung kann durch Web Protection Library erfolgen. Für verwalteten Code (C#, VB.NET usw.) verwenden Sie eine oder mehrere Codierungsmethoden aus der Web Protection (Anti-XSS) Library, die vom Kontext abhängen, in dem die Benutzereingabe manifestiert wird: |
Beispiel
* Encoder.HtmlEncode
* Encoder.HtmlAttributeEncode
* Encoder.JavaScriptEncode
* Encoder.UrlEncode
* Encoder.VisualBasicScriptEncode
* Encoder.XmlEncode
* Encoder.XmlAttributeEncode
* Encoder.CssEncode
* Encoder.LdapEncode
Ausführen der Eingabeüberprüfung und Filtern von Modelleigenschaften aller Zeichenfolgentypen
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein, MVC5, MVC6 |
| Attribute | – |
| Referenzen | Hinzufügen einer Überprüfung, Überprüfen von Modelldaten in einer MVC-Anwendung, Richtlinien für Ihre ASP.NET MVC-Anwendungen |
| Schritte | Alle Eingabeparameter müssen überprüft werden, bevor sie in der Anwendung verwendet werden, um sicherzustellen, dass die Anwendung vor schädlichen Benutzereingaben geschützt ist. Überprüfen Sie die Eingabewerte mit Überprüfungen regulärer Ausdrücke auf Serverseite mit einer Überprüfungsstrategie, die auf einer Zulassungsliste basiert. Durch unbereinigte Benutzereingaben bzw. an die Methode übergebene Parameter kann das Risiko der Codeeinschleusung steigen. Bei Webanwendungen können auch Formularfelder, Abfragezeichenfolgen, Cookies, HTTP-Header und Webdienstparameter mögliche Einstiegspunkte darstellen. Die folgenden Eingabeüberprüfungen müssen bei der Modellbindung ausgeführt werden:
|
Anwenden der Bereinigung auf Felder, die alle Zeichen akzeptieren, z.B. Rich-Text-Editor
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | Codieren unsicherer Eingabe, HTML-Bereinigung |
| Schritte | Identifizieren Sie alle statischen Markuptags, die Sie verwenden möchten. Üblicherweise wird die Formatierung dazu auf sichere HTML-Elemente wie Formatierung Führen Sie vor dem Schreiben der Daten eine HTML-Codierung durch. Damit werden schädliche Skripts sicher, da sie als Text und nicht als ausführbarer Code behandelt werden.
Die Seite in den Verweisen deaktiviert die ASP.NET-Anforderungsvalidierung durch Festlegen von HtmlSanitizer ist eine .NET-Bibliothek zum Bereinigen von HTML-Fragmenten und Dokumenten aus Konstrukten, die zu XSS-Angriffen führen können. Sie verwendet AngleSharp zum Analysieren, Bearbeiten und Rendern von HTML und CSS. HtmlSanitizer kann als ein NuGet-Paket installiert werden, und die Benutzereingabe kann über relevante HTML- oder CSS-Bereinigungsmethoden auf dem Server weitergegeben werden. Die Bereinigung als Sicherheitskontrolle sollte jedoch nur als letzte Option betrachtet werden. Die Überprüfung von Benutzereingaben und Ausgabecodierung gelten als bessere Sicherheitskontrollen. |
Kein Zuweisen von DOM-Elementen, die keine integrierte Codierung aufweisen
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | – |
| Schritte | Viele JavaScript-Funktionen verschlüsseln nicht standardmäßig. Wenn Sie DOM-Elementen über derartige Funktionen Eingaben zuweisen, die nicht vertrauenswürdig sind, kann das zum Ausführen von Cross-Site-Scripting führen. |
Beispiel
Hier einige Beispiele für unsichere Elemente:
document.getElementByID("div1").innerHtml = value;
$("#userName").html(res.Name);
return $('<div/>').html(value)
$('body').append(resHTML);
Verwenden Sie nicht innerHtml, sondern innerText. Verwenden Sie zudem nicht $("#elm").html(), sondern $("#elm").text().
Überprüfen, ob alle Umleitungen innerhalb der Anwendung geschlossen sind oder sicher ausgeführt werden
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | Das OAuth 2.0-Autorisierungsframework – Offene Redirectors |
| Schritte | Anwendungsentwürfe, die eine Umleitung zu einem vom Benutzer bereitgestellten Speicherort erfordern, müssen die möglichen Umleitungsziele auf eine vordefinierte Liste „sicherer“ Standorte oder Domänen einschränken. Alle Umleitungen in der Anwendung müssen geschlossen/sicher sein. Gehen Sie dazu folgendermaßen vor:
|
Implementieren der Eingabeüberprüfung für alle Zeichenfolgentypparameter, die von Controllermethoden akzeptiert werden
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein, MVC5, MVC6 |
| Attribute | – |
| Referenzen | Überprüfen von Modelldaten in einer MVC-Anwendung, Richtlinien für Ihre ASP.NET MVC-Anwendungen |
| Schritte | Für Methoden, die nur einen primitiven Datentyp und keine Modelle als Argument akzeptieren, sollte die Überprüfung der Eingabe mit dem regulären Ausdruck ausgeführt werden. Hier sollte Regex.IsMatch mit einem gültigen Regex-Muster verwendet werden. Wenn die Eingabe nicht mit dem angegebenen regulären Ausdruck übereinstimmt, sollte das Steuerelement nicht fortfahren, und eine entsprechende Warnung hinsichtlich Überprüfungsfehler sollte angezeigt werden. |
Festlegen einer Obergrenze für Timeouts bei der Verarbeitung regulärer Ausdrücke, um DoS aufgrund ungültiger Ausdrücke zu verhindern
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein, Web Forms, MVC5, MVC6 |
| Attribute | – |
| Referenzen | DefaultRegexMatchTimeout-Eigenschaft |
| Schritte | Legen Sie das globale Standardtimeout fest, um DOS-Angriffe auf schlecht erstellte reguläre Ausdrücke sicherzustellen, die zur Rückverfolgung führen. Dauert die Verarbeitungszeit länger als die definierte Obergrenze, wird eine Timeoutausnahme ausgelöst. Wenn nichts konfiguriert ist, wäre das Timeout unendlich. |
Beispiel
Die folgende Konfiguration würde z. B. eine RegexMatchTimeoutException auslösen, wenn die Verarbeitung mehr als 5 Sekunden dauert:
<httpRuntime targetFramework="4.5" defaultRegexMatchTimeout="00:00:05" />
Vermeiden der Verwendung von Html.Raw in Razor-Ansichten
| Titel | Details |
|---|---|
| Komponente | Webanwendung. |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | MVC5, MVC6 |
| Attribute | – |
| Referenzen | – |
| Schritt | ASP.NET WebPages (Razor) führen eine automatische HTML-Codierung durch. Alle von eingebetteten Codenuggets (@-Blöcke) ausgegebenen Zeichenfolgen sind automatisch HTML-codiert. Wird jedoch die HtmlHelper.Raw-Methode aufgerufen, gibt sie Markup ohne HTML-Codierung zurück. Wenn die Html.Raw()-Helfermethode verwendet wird, umgeht sie den automatischen Codierungsschutz von Razor. |
Beispiel
Hier einige Beispiele für unsichere Elemente:
<div class="form-group">
@Html.Raw(Model.AccountConfirmText)
</div>
<div class="form-group">
@Html.Raw(Model.PaymentConfirmText)
</div>
</div>
Verwenden Sie Html.Raw() nur, wenn Markup angezeigt werden muss. Diese Methode führt keine implizite Ausgabecodierung durch. Verwenden Sie andere ASP.NET-Helferprogramme wie @Html.DisplayFor()
Unterlassen dynamischer Abfragen in gespeicherten Prozeduren
| Titel | Details |
|---|---|
| Komponente | Datenbank |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | – |
| Schritte | SQL-Einschleusungsangriffe nutzen Sicherheitslücken bei der Eingabeüberprüfung aus, um beliebige Befehle in der Datenbank auszuführen. Das kann passieren, wenn Ihre Anwendung Eingaben zum Erstellen dynamischer SQL-Anweisungen verwendet, um auf die Datenbank zuzugreifen, oder wenn Ihr Code gespeicherte Prozeduren verwendet, die Zeichenfolgen mit rohen Benutzereingaben übergeben. Mit einem SQL-Einschleusungsangriff kann der Angreifer beliebige Befehle in der Datenbank ausführen. Alle SQL-Anweisungen (einschließlich der SQL-Anweisungen in gespeicherten Prozeduren) müssen parametrisiert werden. Parametrisierte SQL-Anweisungen akzeptieren Zeichen, die für SQL eine besondere Bedeutung haben (z. B. einfache Anführungszeichen), da sie stark typisiert sind. |
Beispiel
Hier ein Beispiel für eine unsichere dynamische gespeicherte Prozedur:
CREATE PROCEDURE [dbo].[uspGetProductsByCriteria]
(
@productName nvarchar(200) = NULL,
@startPrice float = NULL,
@endPrice float = NULL
)
AS
BEGIN
DECLARE @sql nvarchar(max)
SELECT @sql = ' SELECT ProductID, ProductName, Description, UnitPrice, ImagePath' +
' FROM dbo.Products WHERE 1 = 1 '
PRINT @sql
IF @productName IS NOT NULL
SELECT @sql = @sql + ' AND ProductName LIKE ''%' + @productName + '%'''
IF @startPrice IS NOT NULL
SELECT @sql = @sql + ' AND UnitPrice > ''' + CONVERT(VARCHAR(10),@startPrice) + ''''
IF @endPrice IS NOT NULL
SELECT @sql = @sql + ' AND UnitPrice < ''' + CONVERT(VARCHAR(10),@endPrice) + ''''
PRINT @sql
EXEC(@sql)
END
Beispiel
Hier ein Beispiel für die sichere Implementierung der gleichen gespeicherten Prozedur:
CREATE PROCEDURE [dbo].[uspGetProductsByCriteriaSecure]
(
@productName nvarchar(200) = NULL,
@startPrice float = NULL,
@endPrice float = NULL
)
AS
BEGIN
SELECT ProductID, ProductName, Description, UnitPrice, ImagePath
FROM dbo.Products where
(@productName IS NULL or ProductName like '%'+ @productName +'%')
AND
(@startPrice IS NULL or UnitPrice > @startPrice)
AND
(@endPrice IS NULL or UnitPrice < @endPrice)
END
Sicherstellen, dass die Modellvalidierung auf Web-API-Methoden erfolgt ist
| Titel | Details |
|---|---|
| Komponente | Web-API |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | MVC5, MVC6 |
| Attribute | – |
| Referenzen | Modellvalidierung in der ASP.NET-Web-API |
| Schritte | Wenn ein Client Daten an eine Web-API sendet, müssen die Daten vor der Verarbeitung überprüft werden. Nehmen Sie bei ASP.NET-Web-APIs, die Modelle als Eingabe akzeptieren, Datenanmerkungen an Modellen vor, um Validierungsregeln für die Eigenschaften des Modells festzulegen. |
Beispiel
Der folgende Code zeigt das Vorgehen:
using System.ComponentModel.DataAnnotations;
namespace MyApi.Models
{
public class Product
{
public int Id { get; set; }
[Required]
[RegularExpression(@"^[a-zA-Z0-9]*$", ErrorMessage="Only alphanumeric characters are allowed.")]
public string Name { get; set; }
public decimal Price { get; set; }
[Range(0, 999)]
public double Weight { get; set; }
}
}
Beispiel
In der action-Methode der API-Controller muss die Gültigkeit des Modells wie unten dargestellt explizit überprüft werden:
namespace MyApi.Controllers
{
public class ProductsController : ApiController
{
public HttpResponseMessage Post(Product product)
{
if (ModelState.IsValid)
{
// Do something with the product (not shown).
return new HttpResponseMessage(HttpStatusCode.OK);
}
else
{
return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
}
}
}
}
Implementieren der Eingabeüberprüfung für alle Zeichenfolgentypparameter, die von Web-API-Methoden akzeptiert werden
| Titel | Details |
|---|---|
| Komponente | Web-API |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein, MVC 5, MVC 6 |
| Attribute | – |
| Referenzen | Überprüfen von Modelldaten in einer MVC-Anwendung, Richtlinien für Ihre ASP.NET MVC-Anwendungen |
| Schritte | Für Methoden, die nur einen primitiven Datentyp und keine Modelle als Argument akzeptieren, sollte die Überprüfung der Eingabe mit dem regulären Ausdruck ausgeführt werden. Hier sollte Regex.IsMatch mit einem gültigen Regex-Muster verwendet werden. Wenn die Eingabe nicht mit dem angegebenen regulären Ausdruck übereinstimmt, sollte das Steuerelement nicht fortfahren, und eine entsprechende Warnung hinsichtlich Überprüfungsfehler sollte angezeigt werden. |
Sicherstellen, dass typsichere Parameter in Web-API für den Datenzugriff verwendet werden
| Titel | Details |
|---|---|
| Komponente | Web-API |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | – |
| Schritte | Wenn Sie die Parametersammlung verwenden, behandelt SQL die Eingabe als literalen statt ausführbaren Code. Die Parametersammlung kann verwendet werden, um Typ- und Längenbeschränkungen bei Eingabedaten zu erzwingen. Bei Werten außerhalb des Bereichs wird eine Ausnahme ausgelöst. Wenn keine typsicheren SQL-Parameter verwendet werden, können Angreifer möglicherweise Einschleusungsangriffe ausführen, die in die ungefilterte Eingabe eingebettet sind. Verwenden Sie beim Erstellen der SQL-Abfragen typsichere Parameter, um mögliche SQL-Einschleusungsangriffe zu verhindern, die bei ungefilterten Eingaben auftreten können. Sie können typsichere Parameter mit gespeicherten Prozeduren und dynamischen SQL-Anweisungen verwenden. Parameter werden von der Datenbank als literale Werte und nicht als ausführbarer Code behandelt. Parameter werden auch auf Typ und Länge überprüft. |
Beispiel
Der folgende Code zeigt die Verwendung typsicherer Parameter in der SqlParameterCollection beim Aufrufen einer gespeicherten Prozedur.
using System.Data;
using System.Data.SqlClient;
using (SqlConnection connection = new SqlConnection(connectionString))
{
DataSet userDataset = new DataSet();
SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure", connection);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;
myCommand.Fill(userDataset);
}
Im vorigen Codebeispiel darf der Eingabewert darf nicht mehr als 11 Zeichen umfassen. Wenn der Typ oder die Länger der Daten nicht dem vom Parameter definierten Wert entspricht, wird von die Klasse „SqlParameter“ eine Ausnahme ausgelöst.
Verwenden parametrisierter SQL-Abfragen für Azure Cosmos DB
| Titel | Details |
|---|---|
| Komponente | Azure DocumentDB |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein |
| Attribute | – |
| Referenzen | Ankündigung: SQL-Parametrisierung in Azure Cosmos DB |
| Schritte | Azure Cosmos DB unterstützt zwar nur schreibgeschützte Abfragen, jedoch ist SQL-Einschleusung weiterhin möglich, wenn Abfragen durch die Verkettung von Benutzereingaben erstellt werden. Möglicherweise erhält ein Benutzer durch das Erstellen böswilliger Abfragen Zugriff auf Daten, auf die er innerhalb derselben Auflistung nicht zugreifen dürfte. Verwenden Sie parametrisierte SQL-Abfragen, wenn Abfragen basierend auf Benutzereingaben erstellt werden. |
WCF-Eingabeüberprüfung durch Schemabindung
| Titel | Details |
|---|---|
| Komponente | WCF |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein, .NET Framework 3 |
| Attribute | – |
| Referenzen | MSDN |
| Schritte | Bei fehlender Überprüfung sind verschiedenste Einschleusungsangriffe möglich. Die Nachrichtenüberprüfung stellt eine Verteidigungslinie zum Schutz Ihrer WCF-Anwendung dar. Bei diesem Ansatz überprüfen Sie Nachrichten mithilfe von Schemas, um WCF-Dienstvorgänge vor Angriffen durch schädliche Clients zu schützen. Überprüfen Sie alle vom Client empfangenen Nachrichten, um den Client vor Angriffen von einem schädlichen Dienst zu schützen. Die Nachrichtenüberprüfung ermöglicht die Überprüfung von Nachrichten, wenn Vorgänge Nachrichten- oder Datenverträge beanspruchen, die nur mit Parametervalidierung erfolgen können. Mit der Nachrichtenüberprüfung können Sie eine Validierungslogik innerhalb von Schemas erstellen, um mehr Flexibilität zu erhalten und Entwicklungszeit zu verkürzen. Schemas können in verschiedenen Anwendungen innerhalb der Organisation wiederverwendet werden und Standards für die Darstellung der Daten erstellen. Darüber hinaus können Sie mit der Nachrichtenüberprüfung Vorgänge schützen, wenn diese komplexere Datentypen mit Verträgen verwenden, die Geschäftslogik darstellen. Zum Ausführen der Nachrichtenüberprüfung erstellen Sie zuerst ein Schema, das die Vorgänge Ihres Diensts und die Datentypen darstellt, die von diesen Vorgängen beansprucht werden. Anschließend erstellen Sie eine .NET-Klasse, die die an den bzw. von dem Dienst gesendeten/empfangenen Nachrichten mit einem benutzerdefinierten Inspektor für Client- und Verteilernachrichten überprüft. Dann implementieren Sie ein benutzerdefiniertes Endpunktverhalten, um die Nachrichtenüberprüfung auf dem Client und dem Dienst zu aktivieren. Abschließend implementieren Sie ein benutzerdefiniertes Konfigurationselement für die Klasse, das Ihnen ermöglicht, das erweiterte benutzerdefinierte Endpunktverhalten in der Konfigurationsdatei des Dienstes oder des Clients verfügbar zu machen. |
WCF – Eingabeüberprüfung über Parameterinspektoren
| Titel | Details |
|---|---|
| Komponente | WCF |
| SDL-Phase | Entwickeln |
| Zutreffende Technologien | Allgemein, .NET Framework 3 |
| Attribute | – |
| Referenzen | MSDN |
| Schritte | Die Eingabe- und Datenüberprüfung stellt eine wichtige Verteidigungslinie zum Schutz Ihrer WCF-Anwendung dar. Überprüfen Sie alle in WCF-Dienstvorgängen verfügbar gemachten Parameter, um den Dienst vor Angriffen durch schädliche Clients zu schützen. Zudem sollten Sie alle vom Client empfangenen Rückgabewerte überprüfen, um den Client vor Angriffen durch einen schädlichen Dienst zu schützen. WCF bietet verschiedene Erweiterungspunkte, mit denen Sie das WCF-Laufzeitverhalten durch das Erstellen benutzerdefinierter Erweiterungen anpassen können. Nachrichten- und Parameterinspektoren sind zwei Erweiterungsmechanismen, mit denen Sie größere Kontrolle über die Daten erhalten, die zwischen einem Client und einem Dienst weitergegeben werden. Verwenden Sie Parameterinspektoren für die Überprüfung von Benutzereingaben und setzen Sie Nachrichten-Inspektoren nur bei Bedarf ein, um den gesamte Nachrichtenfluss in und aus einem Dienst zu überprüfen. Zum Ausführen der Eingabeüberprüfung erstellen Sie eine .NET-Klasse und implementieren einen benutzerdefinierten Parameterinspektor, um Parameter für Vorgänge in ihrem Dienst zu überprüfen. Dann implementieren Sie ein benutzerdefiniertes Endpunktverhalten, um die Überprüfung auf dem Client und dem Dienst zu aktivieren. Abschließend implementieren Sie ein benutzerdefiniertes Konfigurationselement für die Klasse, das Ihnen ermöglicht, das erweiterte benutzerdefinierte Endpunktverhalten in der Konfigurationsdatei des Dienstes oder des Clients verfügbar zu machen. |