Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Güvenilmeyen stil sayfaları kullanarak tüm dönüşümler için XSLT betiğini devre dışı bırakma
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | XSLT Güvenliği, XsltSettings.EnableScript Özelliği |
| Adımlar | XSLT, öğesini kullanarak stil sayfalarının içinde betik oluşturma işlemini <msxml:script> destekler. Bu, özel işlevlerin XSLT dönüşümünde kullanılmasına olanak tanır. Betik, dönüşümü gerçekleştiren işlemin bağlamı altında yürütülür. Güvenilmeyen kodun yürütülmesini önlemek için güvenilmeyen bir ortamdayken XSLT betiği devre dışı bırakılmalıdır.
.NET kullanılıyorsa: XSLT betiği varsayılan olarak devre dışı bırakılır; ancak özelliği aracılığıyla XsltSettings.EnableScript açıkça etkinleştirilmediğinden emin olmanız gerekir. |
Örnek
XsltSettings settings = new XsltSettings();
settings.EnableScript = true; // WRONG: THIS SHOULD BE SET TO false
Örnek
MSXML 6.0 kullanıyorsanız, XSLT betiği varsayılan olarak devre dışı bırakılır; ancak, AllowXsltScript XML DOM nesne özelliği aracılığıyla açıkça etkinleştirilmediğinden emin olmanız gerekir.
doc.setProperty("AllowXsltScript", true); // WRONG: THIS SHOULD BE SET TO false
Örnek
MSXML 5 veya üzerini kullanıyorsanız, XSLT betiği varsayılan olarak etkindir ve bunu açıkça devre dışı bırakmanız gerekir. ALLOWXsltScript XML DOM nesne özelliğini false olarak ayarlayın.
doc.setProperty("AllowXsltScript", false); // CORRECT. Setting to false disables XSLT scripting.
Kullanıcı tarafından denetlenebilir içerik içerebilen her sayfanın otomatik MIME algılamayı devre dışı bırakdığından emin olun
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | IE8 Güvenlik Bölümü V - Kapsamlı Koruma |
| Adımlar | Kullanıcı tarafından denetlenebilir içerik içerebilen her sayfa için HTTP Üst Bilgisi'ni Bir web sunucusundan teslim edilen her dosya türü, içeriğin doğasını (resim, metin, uygulama vb.) açıklayan ilişkili bir MIME türüne (içerik türü olarak da adlandırılır) sahiptir. X-Content-Type-Options üst bilgisi, geliştiricilerin içeriklerinin MIME koklamaması gerektiğini belirtmesine olanak tanıyan bir HTTP üst bilgisidir. Bu üst bilgi, MIME Algılama saldırılarını azaltmak için tasarlanmıştır. Internet Explorer 8'de (IE8) bu üst bilgi için destek eklendi Yalnızca Internet Explorer 8 (IE8) kullanıcıları X-Content-Type-Options'tan yararlanabilir. Internet Explorer'ın önceki sürümleri şu anda X-Content-Type-Options üst bilgisine saygı duymuyor Internet Explorer 8 (ve üzeri), MIME algılamalı geri çevirme özelliğini uygulayan tek önemli tarayıcılardır. Diğer ana tarayıcılar (Firefox, Safari, Chrome) benzer özellikler uygularsa ve uygulandığında, bu öneri bu tarayıcıların söz dizimlerini de içerecek şekilde güncelleştirilir |
Örnek
Uygulamadaki tüm sayfalar için gerekli üst bilgiyi genel olarak etkinleştirmek için aşağıdakilerden birini yapabilirsiniz:
- Uygulama Internet Information Services (IIS) 7 tarafından barındırılıyorsa web.config dosyasına üst bilgi ekleyin
<system.webServer>
<httpProtocol>
<customHeaders>
<add name=""X-Content-Type-Options"" value=""nosniff""/>
</customHeaders>
</httpProtocol>
</system.webServer>
- Üst bilgiyi genel Application_BeginRequest ekleme
void Application_BeginRequest(object sender, EventArgs e)
{
this.Response.Headers[""X-Content-Type-Options""] = ""nosniff"";
}
- Özel HTTP modülü uygulama
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"");
}
}
- Gerekli üst bilgiyi tek tek yanıtlara ekleyerek yalnızca belirli sayfalar için etkinleştirebilirsiniz:
this.Response.Headers[""X-Content-Type-Options""] = ""nosniff"";
XML Varlık Çözümlemesini Sağlamlaştırma veya Devre Dışı Bırakma
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | XML Varlığı Genişletme, XML Hizmet Reddi Saldırıları ve Savunmaları, MSXML Güvenliğine Genel Bakış, MSXML Kodunun Güvenliğini Sağlamaya Yönelik En İyi Yöntemler, NSXMLParserDelegate Protokol Başvurusu, Dış Başvuruları Çözümleme |
| Adımlar | Yaygın olarak kullanılmasa da, XML ayrıştırıcısının makro varlıklarını belgenin içinde veya dış kaynaklardan tanımlanan değerlerle genişletmesine olanak tanıyan bir XML özelliği vardır. Örneğin, belgede "&companyname;" metni her görüntülendiğinde otomatik olarak Microsoft metniyle değiştirilebilmesi için belge "Microsoft" değerine sahip bir "şirketadı" varlığı tanımlayabilir. Veya belge, Microsoft hisse senedinin geçerli değerini getirmek için bir dış web hizmetine başvuran bir "MSFTStock" varlığı tanımlayabilir. Daha sonra belgede "&MSFTStock;" göründüğünde otomatik olarak geçerli hisse senedi fiyatıyla değiştirilir. Ancak bu işlevsellik, hizmet reddi (DoS) koşulları oluşturmak için kötüye kullanılabilir. Saldırgan, sistemdeki tüm kullanılabilir belleği tüketen bir üstel genişletme XML bombası oluşturmak için birden çok varlığı iç içe alabilir. Alternatif olarak, sonsuz miktarda veri akışı sağlayan veya yalnızca iş parçacığını kilitleyen bir dış başvuru oluşturabilir. Sonuç olarak, tüm takımlar, uygulamaları bunu kullanmıyorsa iç ve/veya dış XML varlık çözümlemesini tamamen devre dışı bırakmalı veya bu işlevsellik kesinlikle gerekliyse, uygulamanın varlık çözümlemesi için kullanabileceği bellek ve süreyi el ile sınırlamalıdır. Uygulamanızın varlık çözümlemesi gerekmiyorsa, devre dışı bırakın. |
Örnek
.NET Framework kodu için aşağıdaki yaklaşımları kullanabilirsiniz:
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);
değerinin XmlReaderSettings varsayılan değerinin ProhibitDtd true, ancak içinde XmlTextReader false olduğunu unutmayın. XmlReaderSettings kullanıyorsanız, ProhibitDtd değerini açıkça true olarak ayarlamanız gerekmez, ancak güvenlik açısından bunu yapmanız önerilir. XmlDocument sınıfının varsayılan olarak varlık çözümlemesine izin verdiğine de dikkat edin.
Örnek
XmlDocument'lar için varlık çözümlemesini devre dışı bırakmak için Load yönteminin aşırı yüklemesini kullanın XmlDocument.Load(XmlReader) ve xmlreader bağımsız değişkenindeki uygun özellikleri aşağıdaki kodda gösterildiği gibi çözümlemeyi devre dışı bırakmak üzere ayarlayın:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = true;
XmlReader reader = XmlReader.Create(stream, settings);
XmlDocument doc = new XmlDocument();
doc.Load(reader);
Örnek
Uygulamanız için varlık çözümlemesini devre dışı bırakmak mümkün değilse XmlReaderSettings.MaxCharactersFromEntities özelliğini uygulamanızın gereksinimlerine göre makul bir değere ayarlayın. Bu, olası üstel genişletme DoS saldırılarının etkisini sınırlandıracaktır. Aşağıdaki kod bu yaklaşımın bir örneğini sağlar:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = false;
settings.MaxCharactersFromEntities = 1000;
XmlReader reader = XmlReader.Create(stream, settings);
Örnek
Satır içi varlıkları çözümlemeniz gerekiyorsa ancak dış varlıkları çözümlemeniz gerekmiyorsa XmlReaderSettings.XmlResolver özelliğini null olarak ayarlayın. Örneğin:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = false;
settings.MaxCharactersFromEntities = 1000;
settings.XmlResolver = null;
XmlReader reader = XmlReader.Create(stream, settings);
MSXML6'da, ProhibitDTD'nin varsayılan olarak true (DTD işlemeyi devre dışı bırakma) olarak ayarlandığını unutmayın. Apple OSX/iOS kodu için kullanabileceğiniz iki XML ayrıştırıcısı vardır: NSXMLParser ve libXML2.
URL kurallılaştırma doğrulaması gerçekleştirmek http.sys kullanan uygulamalar
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | Yok |
| Adımlar | http.sys kullanan tüm uygulamalar şu yönergeleri izlemelidir:
|
Kullanıcılardan dosya kabul ederken uygun denetimlerin yapıldığından emin olun
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | Kısıtlanmamış Dosya Yükleme, Dosya İmzası Tablosu |
| Adımlar | Karşıya yüklenen dosyalar uygulamalar için önemli bir risk oluşturur. Birçok saldırının ilk adımı, sisteme saldırılacak bazı kodlar almaktır. Ardından saldırının yalnızca kodu yürütmenin bir yolunu bulması gerekir. Dosya yükleme kullanmak, saldırganın ilk adımı gerçekleştirmesine yardımcı olur. Sınırsız dosya yükleme işleminin sonuçları, tam sistem devralma, aşırı yüklenmiş bir dosya sistemi veya veritabanı, saldırıları arka uç sistemlerine iletme ve basit yok etme gibi değişiklikler gösterebilir. Uygulamanın karşıya yüklenen dosyayla ne yaptığına ve özellikle nerede depolandığına bağlıdır. Dosya yüklemelerinin sunucu tarafı doğrulaması eksik. Dosya Yükleme işlevi için aşağıdaki güvenlik denetimleri uygulanmalıdır:
|
Örnek
Dosya biçimi imza doğrulamasıyla ilgili son nokta için ayrıntılar için aşağıdaki sınıfa bakın:
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;
}
Web Uygulamasında veri erişimi için tür açısından güvenli parametrelerin kullanıldığından emin olun
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | Yok |
| Adımlar | Parameters koleksiyonunu kullanırsanız, SQL girişi yürütülebilir kod yerine değişmez değer olarak değerlendirir. Parameters koleksiyonu, giriş verilerinde tür ve uzunluk kısıtlamalarını zorlamak için kullanılabilir. Aralığın dışındaki değerler bir özel durum tetikler. Tür açısından güvenli SQL parametreleri kullanılmıyorsa, saldırganlar filtrelenmemiş girişe eklenmiş ekleme saldırılarını yürütebilir. Filtrelenmemiş girişle gerçekleşebilecek olası SQL ekleme saldırılarını önlemek için SQL sorguları oluştururken tür güvenli parametreleri kullanın. Tür güvenli parametrelerini saklı yordamlarla ve dinamik SQL deyimleriyle kullanabilirsiniz. Parametreler, yürütülebilir kod olarak değil veritabanı tarafından değişmez değer olarak değerlendirilir. Parametreler ayrıca tür ve uzunluk açısından da denetlenmektedir. |
Örnek
Aşağıdaki kod, saklı yordamı çağırırken SqlParameterCollection ile tür güvenli parametrelerinin nasıl kullanılacağını gösterir.
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);
}
Yukarıdaki kod örneğinde, giriş değeri 11 karakterden uzun olamaz. Veriler parametresi tarafından tanımlanan türe veya uzunluğa uymuyorsa, SqlParameter sınıfı bir özel durum oluşturur.
MVC toplu atama güvenlik açığını önlemek için ayrı model bağlama sınıfları veya bağlama filtre listeleri kullanın
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | MVC5, MVC6 |
| Öznitelikler | Yok |
| Başvurular | Meta Veri Öznitelikleri, Ortak Anahtar Güvenliği Güvenlik Açığı ve Risk Azaltma, ASP.NET MVC'de Toplu Atama için Eksiksiz Kılavuz, MVC Kullanarak EF'yi Kullanmaya Başlama |
| Adımlar |
|
İşlemeden önce güvenilmeyen web çıkışını kodlama
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel, Web Forms, MVC5, MVC6 |
| Öznitelikler | Yok |
| Başvurular | ASP.NET, Siteler Arası Betik, XSS (Siteler Arası Betik Oluşturma) Önleme Bilgi Sayfası'nda Siteler Arası betiği önleme |
| Adımlar | Siteler arası betik oluşturma (genellikle XSS olarak kısaltılır), çevrimiçi hizmetler veya web'den giriş kullanan herhangi bir uygulama/bileşen için bir saldırı vektördür. XSS güvenlik açıkları, saldırganın güvenlik açığı bulunan bir web uygulaması aracılığıyla başka bir kullanıcının makinesinde betik yürütmesine izin verebilir. Kötü amaçlı betikler, JavaScript aracılığıyla tanımlama bilgilerini çalmak ve başka bir şekilde kurbanın makinesiyle oynama yapmak için kullanılabilir. XSS, bir web sayfasında işlenmeden önce iyi biçimlendirildiğinden ve kodlandığından emin olarak kullanıcı girişi doğrulanarak engellenir. Giriş doğrulama ve çıkış kodlaması Web Koruma Kitaplığı kullanılarak yapılabilir. Yönetilen kod (C#, VB.NET vb.) için, kullanıcı girişinin bildirildiği bağlama bağlı olarak Web Koruması (XSS Koruması) Kitaplığı'ndan bir veya daha fazla uygun kodlama yöntemi kullanın: |
Örnek
* Encoder.HtmlEncode
* Encoder.HtmlAttributeEncode
* Encoder.JavaScriptEncode
* Encoder.UrlEncode
* Encoder.VisualBasicScriptEncode
* Encoder.XmlEncode
* Encoder.XmlAttributeEncode
* Encoder.CssEncode
* Encoder.LdapEncode
Tüm dize türü Model özelliklerinde giriş doğrulama ve filtreleme gerçekleştirme
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel, MVC5, MVC6 |
| Öznitelikler | Yok |
| Başvurular | MVC Uygulamasında Doğrulama, Model Verilerini Doğrulama, ASP.NET MVC Uygulamalarınız için Yol Gösteren İlkeler |
| Adımlar | Uygulamanın kötü amaçlı kullanıcı girişlerine karşı korunmasını sağlamak için tüm giriş parametrelerinin uygulamada kullanılmadan önce doğrulanması gerekir. İzin verilen liste doğrulama stratejisiyle sunucu tarafında normal ifade doğrulamalarını kullanarak giriş değerlerini doğrulayın. Yöntemlere geçirilen sağlıksız kullanıcı girişleri/parametreleri kod ekleme güvenlik açıklarına neden olabilir. Web uygulamaları için giriş noktaları form alanlarını, QueryString'leri, tanımlama bilgilerini, HTTP üst bilgilerini ve web hizmeti parametrelerini de içerebilir. Model bağlaması sırasında aşağıdaki giriş doğrulama denetimleri gerçekleştirilmelidir:
|
Temizleme, zengin metin düzenleyicisi gibi tüm karakterleri kabul eden form alanlarına uygulanmalıdır
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | Güvenli Olmayan Girişi Kodlama, HTML Dezenfektanı |
| Adımlar | Kullanmak istediğiniz tüm statik işaretleme etiketlerini tanımlayın. Biçimlendirmeyi (kalın) ve Verileri yazmadan önce HTML ile kodlayın. Bu, herhangi bir kötü amaçlı betiğin yürütülebilir kod olarak değil metin olarak işlenmesine neden olarak güvenli hale getirir.
Başvurulardaki sayfa ayarıyla HtmlSanitizer, XSS saldırılarına neden olabilecek yapılardan HTML parçalarını ve belgelerini temizlemeye yönelik bir .NET kitaplığıdır. HTML ve CSS'yi ayrıştırmak, işlemek ve işlemek için AngleSharp kullanır. HtmlSanitizer bir NuGet paketi olarak yüklenebilir ve kullanıcı girişi ilgili HTML veya CSS temizleme yöntemlerinden (uygun olduğu şekilde sunucu tarafında) geçirilebilir. Güvenlik denetimi olarak temizlemenin yalnızca son seçenek olarak kabul edilmesi gerektiğini lütfen unutmayın. Giriş doğrulama ve Çıkış Kodlaması daha iyi güvenlik denetimleri olarak kabul edilir. |
Yerleşik kodlaması olmayan havuzlara DOM öğeleri atama
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | Yok |
| Adımlar | Birçok JavaScript işlevi varsayılan olarak kodlama yapmaz. Bu tür işlevler aracılığıyla DOM öğelerine güvenilmeyen giriş atarken siteler arası betik (XSS) yürütmelerine neden olabilir. |
Örnek
Aşağıda güvenli olmayan örnekler verilmiştir:
document.getElementByID("div1").innerHtml = value;
$("#userName").html(res.Name);
return $('<div/>').html(value)
$('body').append(resHTML);
innerHtmlkullanmayın; yerine kullanıninnerText. Benzer şekilde, yerine $("#elm").html()kullanın. $("#elm").text()
Uygulama içindeki tüm yeniden yönlendirmelerin kapalı olduğunu veya güvenli bir şekilde yapıldığını doğrulayın
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | OAuth 2.0 Yetkilendirme Çerçevesi - Yeniden Yönlendiricileri Aç |
| Adımlar | Kullanıcı tarafından sağlanan bir konuma yeniden yönlendirme gerektiren uygulama tasarımı, olası yeniden yönlendirme hedeflerini önceden tanımlanmış bir "güvenli" site veya etki alanı listesine kısıtlamalıdır. Uygulamadaki tüm yeniden yönlendirmeler kapatılmalıdır/güvenli olmalıdır. Bunu yapmak için:
|
Denetleyici yöntemleri tarafından kabul edilen tüm dize türü parametrelerinde giriş doğrulamayı uygulama
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel, MVC5, MVC6 |
| Öznitelikler | Yok |
| Başvurular | MVC Uygulamasında Model Verilerini Doğrulama, ASP.NET MVC Uygulamalarınız için Yol Gösteren İlkeler |
| Adımlar | Modelleri bağımsız değişken olarak değil yalnızca ilkel veri türünü kabul eden yöntemler için Normal İfade kullanılarak giriş doğrulaması yapılmalıdır. Burada Regex.IsMatch geçerli bir regex deseni ile kullanılmalıdır. Giriş belirtilen Normal İfade ile eşleşmiyorsa denetim daha fazla ilerlememelidir ve doğrulama hatasıyla ilgili yeterli bir uyarı görüntülenmelidir. |
Hatalı normal ifadeler nedeniyle DoS'yi önlemek için normal ifade işleme için üst sınır zaman aşımı ayarlayın
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel, Web Forms, MVC5, MVC6 |
| Öznitelikler | Yok |
| Başvurular | DefaultRegexMatchTimeout Özelliği |
| Adımlar | Kötü oluşturulmuş normal ifadelere karşı çok fazla geri izlemeye neden olan hizmet reddi saldırılarını sağlamak için genel varsayılan zaman aşımını ayarlayın. İşleme süresi tanımlanan üst sınırdan daha uzun sürerse zaman aşımı özel durumu oluşturur. Hiçbir şey yapılandırılmazsa zaman aşımı sonsuz olur. |
Örnek
Örneğin, işleme 5 saniyeden uzun sürüyorsa aşağıdaki yapılandırma bir RegexMatchTimeoutException oluşturur:
<httpRuntime targetFramework="4.5" defaultRegexMatchTimeout="00:00:05" />
Razor görünümlerinde Html.Raw kullanmaktan kaçının
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web Uygulaması |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | MVC5, MVC6 |
| Öznitelikler | Yok |
| Başvurular | Yok |
| Adım | ASP.NET WebPages (Razor) otomatik HTML kodlaması gerçekleştirir. Eklenmiş kod parçacıkları (@ blokları) tarafından yazdırılan tüm dizeler otomatik olarak HTML ile kodlanır. Ancak, Yöntem çağrıldığında HtmlHelper.Raw HTML kodlu olmayan işaretleme döndürür. Yardımcı yöntemi kullanılırsa Html.Raw() Razor'ın sağladığı otomatik kodlama korumasını atlar. |
Örnek
Aşağıda güvenli olmayan bir örnek verilmiştir:
<div class="form-group">
@Html.Raw(Model.AccountConfirmText)
</div>
<div class="form-group">
@Html.Raw(Model.PaymentConfirmText)
</div>
</div>
İşaretlemeyi görüntülemeniz gerekmedikçe kullanmayın Html.Raw() . Bu yöntem örtük olarak çıkış kodlaması gerçekleştirmez. Diğer ASP.NET yardımcılarını kullanın; örneğin, @Html.DisplayFor()
Saklı yordamlarda dinamik sorgu kullanmayın
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Veritabanı |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | Yok |
| Adımlar | SQL ekleme saldırısı, veritabanında rastgele komutlar çalıştırmak için giriş doğrulamadaki güvenlik açıklarından yararlanıyor. Uygulamanız veritabanına erişmek için dinamik SQL deyimleri oluşturmak için giriş kullandığında oluşabilir. Ayrıca kodunuz ham kullanıcı girişi içeren geçirilen dizeler olan saklı yordamları kullanıyorsa da oluşabilir. Saldırgan, SQL ekleme saldırısını kullanarak veritabanında rastgele komutlar yürütebilir. Tüm SQL deyimleri (saklı yordamlardaki SQL deyimleri dahil) parametrelendirilmelidir. Parametreli SQL deyimleri, sql için özel anlamı olan karakterleri (tek tırnak gibi) sorunsuz kabul eder çünkü bunlar kesin olarak yazılır. |
Örnek
Aşağıda güvenli olmayan dinamik Saklı Yordam örneği verilmiştir:
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
Örnek
Aşağıda, güvenli bir şekilde uygulanan aynı saklı yordam yer alır:
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
Model doğrulamasının Web API'sinde yapıldığından emin olun
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web API'si |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | MVC5, MVC6 |
| Öznitelikler | Yok |
| Başvurular | ASP.NET Web API'sinde Model Doğrulama |
| Adımlar | İstemci bir web API'sine veri gönderdiğinde, herhangi bir işlem yapmadan önce verilerin doğrulanması zorunludur. Modelleri giriş olarak kabul eden ASP.NET Web API'leri için modellerdeki veri ek açıklamalarını kullanarak modelin özellikleri üzerinde doğrulama kuralları ayarlayın. |
Örnek
Aşağıdaki kodda da aynı şey gösterilmektedir:
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; }
}
}
Örnek
API denetleyicilerinin eylem yönteminde, aşağıda gösterildiği gibi modelin geçerliliğinin açıkça denetlenmiş olması gerekir:
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);
}
}
}
}
Web API yöntemleri tarafından kabul edilen tüm dize türü parametrelerinde giriş doğrulaması uygulama
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web API'si |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel, MVC 5, MVC 6 |
| Öznitelikler | Yok |
| Başvurular | MVC Uygulamasında Model Verilerini Doğrulama, ASP.NET MVC Uygulamalarınız için Yol Gösteren İlkeler |
| Adımlar | Modelleri bağımsız değişken olarak değil yalnızca ilkel veri türünü kabul eden yöntemler için Normal İfade kullanılarak giriş doğrulaması yapılmalıdır. Burada Regex.IsMatch geçerli bir regex deseni ile kullanılmalıdır. Giriş belirtilen Normal İfade ile eşleşmiyorsa denetim daha fazla ilerlememelidir ve doğrulama hatasıyla ilgili yeterli bir uyarı görüntülenmelidir. |
Veri erişimi için Web API'sinde tür açısından güvenli parametrelerin kullanıldığından emin olun
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Web API'si |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | Yok |
| Adımlar | Parameters koleksiyonunu kullanırsanız, SQL girişi yürütülebilir kod yerine değişmez değer olarak değerlendirir. Parameters koleksiyonu, giriş verilerinde tür ve uzunluk kısıtlamalarını zorlamak için kullanılabilir. Aralığın dışındaki değerler bir özel durum tetikler. Tür açısından güvenli SQL parametreleri kullanılmıyorsa, saldırganlar filtrelenmemiş girişe eklenmiş ekleme saldırılarını yürütebilir. Filtrelenmemiş girişle gerçekleşebilecek olası SQL ekleme saldırılarını önlemek için SQL sorguları oluştururken tür güvenli parametreleri kullanın. Tür güvenli parametrelerini saklı yordamlarla ve dinamik SQL deyimleriyle kullanabilirsiniz. Parametreler, yürütülebilir kod olarak değil veritabanı tarafından değişmez değer olarak değerlendirilir. Parametreler ayrıca tür ve uzunluk açısından da denetlenmektedir. |
Örnek
Aşağıdaki kod, saklı yordamı çağırırken SqlParameterCollection ile tür güvenli parametrelerinin nasıl kullanılacağını gösterir.
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);
}
Yukarıdaki kod örneğinde, giriş değeri 11 karakterden uzun olamaz. Veriler parametresi tarafından tanımlanan türe veya uzunluğa uymuyorsa, SqlParameter sınıfı bir özel durum oluşturur.
Azure Cosmos DB için parametreli SQL sorgularını kullanma
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | Azure Belge VERITABANı |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel |
| Öznitelikler | Yok |
| Başvurular | Azure Cosmos DB'de SQL Parametreleştirme duyurusunda |
| Adımlar | Azure Cosmos DB yalnızca salt okunur sorguları desteklese de, sorgular kullanıcı girişiyle birleşerek oluşturulursa SQL ekleme işlemi yine de mümkündür. Bir kullanıcının kötü amaçlı SQL sorguları oluşturarak aynı koleksiyon içinde erişmemesi gereken verilere erişmesi mümkün olabilir. Sorgular kullanıcı girişlerine göre oluşturulduysa parametreli SQL sorgularını kullanın. |
Şema bağlaması aracılığıyla WCF Girişi doğrulaması
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | WCF |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel, NET Framework 3 |
| Öznitelikler | Yok |
| Başvurular | MSDN |
| Adımlar | Doğrulama eksikliği farklı tür ekleme saldırılarına yol açar. İleti doğrulama, WCF uygulamanızın korunmasında bir savunma hattını temsil eder. Bu yaklaşımla, WCF hizmeti işlemlerini kötü amaçlı bir istemcinin saldırılarına karşı korumak için şemaları kullanarak iletileri doğrularsınız. İstemciyi kötü amaçlı bir hizmetin saldırılarına karşı korumak için istemci tarafından alınan tüm iletileri doğrulayın. İleti doğrulama, işlemler ileti sözleşmelerini veya veri sözleşmelerini kullandığında iletileri doğrulamayı mümkün kılar ve bu işlem parametre doğrulaması kullanılarak yapılamaz. İleti doğrulama, şemaların içinde doğrulama mantığı oluşturmanıza olanak sağlayarak daha fazla esneklik sağlar ve geliştirme süresini kısaltabilirsiniz. Şemalar kuruluş içindeki farklı uygulamalarda yeniden kullanılabilir ve veri gösterimi için standartlar oluşturulur. Ayrıca, ileti doğrulama, iş mantığını temsil eden sözleşmeler içeren daha karmaşık veri türlerini kullandıklarında işlemleri korumanıza olanak tanır. İleti doğrulama gerçekleştirmek için önce hizmetinizin işlemlerini ve bu işlemler tarafından kullanılan veri türlerini temsil eden bir şema oluşturursunuz. Ardından, hizmete gönderilen/hizmetten gönderilen/alınan iletileri doğrulamak için özel istemci ileti denetçisi ve özel dağıtıcı ileti denetçisi uygulayan bir .NET sınıfı oluşturursunuz. Ardından, hem istemcide hem de hizmette ileti doğrulamayı etkinleştirmek için özel bir uç nokta davranışı uygularsınız. Son olarak, sınıfına hizmetin veya istemcinin yapılandırma dosyasında genişletilmiş özel uç nokta davranışını kullanıma sunmanızı sağlayan özel bir yapılandırma öğesi uygularsınız" |
WCF- Parametre Denetçileri aracılığıyla giriş doğrulama
| Başlık | Ayrıntılar |
|---|---|
| Bileşen | WCF |
| SDL Aşaması | Derleme |
| Geçerli Teknolojiler | Genel, NET Framework 3 |
| Öznitelikler | Yok |
| Başvurular | MSDN |
| Adımlar | Giriş ve veri doğrulama, WCF uygulamanızın korunmasında önemli bir savunma hattını temsil eder. Hizmeti kötü amaçlı bir istemcinin saldırılarına karşı korumak için WCF hizmet işlemlerinde kullanıma sunulan tüm parametreleri doğrulamanız gerekir. Buna karşılık, istemciyi kötü amaçlı bir hizmetin saldırılarına karşı korumak için istemci tarafından alınan tüm dönüş değerlerini de doğrulamanız gerekir WCF, özel uzantılar oluşturarak WCF çalışma zamanı davranışını özelleştirmenize olanak sağlayan farklı genişletilebilirlik noktaları sağlar. İleti Denetçileri ve Parametre Denetçileri, istemci ile hizmet arasında geçen veriler üzerinde daha fazla denetim elde etmek için kullanılan iki genişletilebilirlik mekanizmasıdır. Giriş doğrulaması için parametre denetçilerini ve ileti denetçilerini yalnızca bir hizmette akan ve giden iletinin tamamını incelemeniz gerektiğinde kullanmanız gerekir. Giriş doğrulama gerçekleştirmek için bir .NET sınıfı oluşturacak ve hizmetinizdeki işlemlerde parametreleri doğrulamak için özel parametre denetçisi uygulayacaksınız. Ardından hem istemcide hem de hizmette doğrulamayı etkinleştirmek için özel bir uç nokta davranışı uygulayacaksınız. Son olarak, sınıfında hizmetin veya istemcinin yapılandırma dosyasında genişletilmiş özel uç nokta davranışını kullanıma sunmanızı sağlayan özel bir yapılandırma öğesi uygulayacaksınız |