https päring SQL serveri CLR protseduurist

Igasugu asju võimaldatakse ka andmebaasis teha CLR-iga aga kui vaja teha sertifikaadikindel https postitus võib seda teha nii.

Et serveri sertifikaatide veateadetest lahti saada tuleb kasutada
ServicePointManager.ServerCertificateValidationCallback meetodi ülekirjutamist

using System.Security.Cryptography.X509Certificates;
using System.Net.Security;
using System.Net;
using System.IO;


private static bool ValidateRemoteCertificate( object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors )
{
//siia võib mingi mõistliku veatöötluse juurde arendada, praegu annab alati true, ehk kõikidest vigadest läheb mööda.
return true;
}

CLR protseduur ise

[Microsoft.SqlServer.Server.SqlProcedure]
public static void VeebiParing(SqlString url, SqlString andmed, SqlString kellelt, out SqlString outt)
{
try
{
//see on sertifikaadi veast möödahiilimiseks
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);

HttpWebRequest myRequest=(HttpWebRequest)System.Net.WebRequest.Create((string)url);

myRequest.Method = "POST";
myRequest.ContentType = "application/x-www-form-urlencoded";


//paneme sisu kokku
StringBuilder postData = new StringBuilder();
//siin paneb andmed külge
postData.Append("Saadame="+(string)kellelt+"&andmeid="+(string)andmed);


//päringu andmete sisu tuleb läbi System.Uri.EscapeUriString lasta, muidu ei lähe läbi veebi.
string data = System.Text.Encoding.GetEncoding("UTF-8").GetBytes(System.Uri.EscapeUriString(postData.ToString()));
myRequest.ContentLength = data.Length;

// Striim veebi saatmiseks

Stream newStream = myRequest.GetRequestStream();
// Saadame minema
newStream.Write(data, 0, data.Length);
newStream.Close();

//loeme vastuse

HttpWebResponse loWebResponse = (HttpWebResponse)myRequest.GetResponse();

Encoding enc = System.Text.Encoding.GetEncoding("UTF-8");
StreamReader loResponseStream = new StreamReader(loWebResponse.GetResponseStream(), enc);
//kuna on protseduur siis nii saab sisulistvastust tagastada
outt = loResponseStream.ReadToEnd();
loResponseStream.Close();
loWebResponse.Close();

}
catch ( WebException ex)
{
outt = "WebException: " + ex.Message;
}
catch (SystemException ex)
{
outt="Error: "+ex.Message;
}
return;

}

Kui andmebaas hakkab CLR alusel protseduuri looma siis NVARCHAR(4000) sisendparameetri võid muuta NVARCHAR(MAX) peale ja ASSEMBLY tuleb teha UNSAFE märgendiga, mis annab CLR protseduurile turvalisuse seisukohalt laiad võimalused ehk kaaluda tasub muude võimaluste kasutamist

AjaxToolkit NotBot extender näitab osadele BruteForce tööriistadele trääsa

Alates ASP.NET 3.5 versioonist ka Ajax NotBot extender olemas. Kasutada saab näiteks BruteForce tööriistade vastu, mis salasõnade äraarvamisega süsteemi sisse pääseda püüavad.

Päringute arve piiramine(RequestRateLimiting) aitab ka siin nagu tavaliselt alati.

Peale extenderi vormile lohistamist saab mängida peamiselt kolme parameetriga

ResponseMinimumDelaySeconds="3" tähendab seda, et peale veebivormi avanemist(allalaadimist) peab ootama 3 sekundit ennem kui PostBack serveri poolt töötlemisele võetakse

CutoffMaximumInstances="8" ja CutoffWindowSeconds="50" määravad ära, et "luba 50 sekundi jooksul ainult 8 korda PostBack-i teha". Maakeeli tähendab seda, et 50 sekundi jooksul saab ainult 8 korda salasõna äraarvamist proovida


Code-behindi võib näiteks teha niimoodi (soovitav lisada ka veateate hägustamise osa)

protected void ButtonLogin_Click(object sender, EventArgs e)
{

AjaxControlToolkit.NoBotState nbstate;
if (!this.NoBot1.IsValid(out nbstate))
{
switch (nbstate)
{
case AjaxControlToolkit.NoBotState.InvalidResponseTooSoon: //liiga vara sisestati peale vormi laadimist
{
this.CustomValidatorLoginFailed.ErrorMessage = "Liiga kiiresti alustasite";
break;
}
case AjaxControlToolkit.NoBotState.InvalidAddressTooActive: //liiga kiiresti sisestatakse lubatud ajavahemiku jooksul
{
this.CustomValidatorLoginFailed.ErrorMessage = "Liiga sageli proovite";
break;
}
default:
{
this.CustomValidatorLoginFailed.ErrorMessage = "BotRobot " + nbstate;
break;

}
}
this.CustomValidatorLoginFailed.IsValid = false;
return;
}
//siit saati võib nüüd päringut töötlema asuda
}

applicationHost.config faili asukoht 32-bitistel arvutitel

Asub siin
C:\Windows\System32\inetsrv\config

Kui hakkad IIS7 all näiteks web.config faili RequestFiltering sektsiooni
sisse kirjutama ja pistab kisama, a'la

This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

siis põhjus selles, et applicationHost.config failis on

<section name="requestFiltering" overrideModeDefault="Deny">

keelatud web.config failides requestFiltering osa muuta

Lubada saad, kui muuta applicationHost.config failis overrideModeDefault="Allow"

peale seda iisreset ja võtab taas pildi ette

Kuupäeva pp.kk.aaaa formaadipööramine

Ei meeldi .NET-ile pp.kk.aaaa kuupäeva formaat, igalt poolt võib hakata exceptioneid pilduma, usaldusväärsust lisab fikseeritud formaatidega tüübipööramine

string kuupaevatekst="23.10.2010";

DateTime arvekuupaev;
string[] formaat = new string[4];
formaat[0] = "yyyy-MM-dd"; //.NET standardformaat
formaat[1] = "MM.dd.yyyy";
formaat[2] = "dd.MM.yyyy"; //meie kullakallis pp.kk.aaaa
formaat[3] = "yyyyMMdd"; /ISO8601 see töötab alati nii .NET kui SQL SERVER
if (!System.DateTime.TryParseExact(kuupaevatekst, formaat, System.Globalization.CultureInfo.InvariantCulture,
System.Globalization.DateTimeStyles.None, out arvekuupaev))
{
throw new InvalidOperationException("Error !! kuupäev " + kuupaevatekst+ " pole sobivas formaadis");
}

ja töötab palju paremini
arvekuupaev siin on nüüd kuupäevaks teisendatud string

GetSafeHtmlFragment AntiXSS 4.0 Librarys on nüüd Sanitizer klassis

Valget nimekirja kasutavas Anti-Cross Site Scripting Library V4.0
http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=f4cd231b-7e06-445b-bec7-343e5884e651
on GetSafeHtmlFragment meetod nüüd Sanitizer klassis endise AntiXss klassi asemel.
Sanitizer klassi meetodid GetSafeHtml ja GetSafeHtmlFragment vaatavad sisendit
Principle of Inclusions põhimõtte järgi ja kui leitakse midagi, mis ei ole valges nimekirjas siis tõmmatakse väljundist maha

Näiteks varjestamist vajavast tekstist

Salakood <script type="text/javascript">prompt('Sisesta PIN kood'); </script>

jätab GetSafeHtmlFragment alles ainult Salakood osa


GetSafeHtml aga teeb

<html>
<body>
Salakood
</body>
</html>

HTML-i

Kasutamiseks lisa viited DLL -idele HtmlSanitizationLibray ja AntiXSSLibrary

Koodis kasuta
Microsoft.Security.Application.Sanitizer.GetSafeHtmlFragment(Eval("textboxtest").ToString())

MS10-070 ASP.NET Padding Oracle turvapaik muudab IIS7 peal ScriptResource.axd ja WebResource.axd pöördumise URL-i pikemaks

Peale patchi rakendamist, ei pruugi veebirakendus enam töödata
http://www.dt.ee/blog/kood/net/2010/09/kriitilise-tahtsusega-turvapaik-aspnet-jaoks

Muudatus, mis patchiga tuleb on see, et kui kasutad RequestFilteringi siis suurenda MaxUrli pikkust. WebResource.axd ja ScriptResource.axd poole pöördumised on nüüd pikemad



<location path="WebResource.axd">
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="230" />
</requestFiltering>
</security>
</system.webServer>
</location>


<location path="ScriptResource.axd">
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="230" />
</requestFiltering>
</security>
</system.webServer>
</location>

Pimesüstimisautomaadi takistamine veateate edastamise juhusliku viivitamisega

Blind Injection (pimesüstimine) on meetod kus serverisse saadud päringu vastusest ei loe otse välja sind huvitavat infot vaid selle teadasaamiskes tuleb kasutada meetodid, kus näiteks kontrollitakse, kas veateade tuli või ei tulnud.
Pimesüstimise erijuhtum on ajaliselt vastuse saabumise mõõtmine.

Mõned SQL pimesüstimise meetodid on mul kirjeldatud Arvutimaailma artiklis
www.am.ee/sql

Ründaja elu saab raskemaks teha, kui panna teatud juhuslikkus sisse veateate tagastamisse, ehk
web.config failis otsib rida customErrors, kus vigade korral suunab endatehtud veateadete veebilehele,

customErrors defaultRedirect="MinuError.aspx" redirectMode="ResponseRewrite"

MinuError.aspx on veebileht, kuhu kasutaja vea ilmumisel suuname ja sinna ehitab sisse
juhusliku ajalise viivitamise Page_Load meetodisse

//kõigepealt püüab veateate kinni
Exception ex = Server.GetLastError().GetBaseException();
if (ex != null)
{

//tark on veateated kodeerida XSS rünnakute vastu
this.LiteralViga.Text = Server.HtmlEncode(ex.Message.Trim());

// see osa teeb veateate andmisel juhusliku ajalise viivituse, et vältida veateadete vastuste põhjal andmete leket pimesüstimise meetodit kasutades
//veateate vastuse saadame tagasi teatud juhtudel juhusliku pausi järel
byte[] delay = new byte[1];
System.Security.Cryptography.RandomNumberGenerator rnd = new System.Security.Cryptography.RNGCryptoServiceProvider();
rnd.GetBytes(delay);
int viiv = (int)delay[0];

if (viiv < 25) //veateadet ei saada kohe vaid teeb juhusliku pikema ajalise pausi sisse mõningatel juhtudel
{
viiv=viiv*666; //ka mina olen kuri :)
System.Threading.Thread.Sleep(viiv);
IDisposable disposable = rnd as IDisposable;
if (disposable != null)
{ disposable.Dispose(); } //mälu vabaks
}
}

Alati võib ise mõelda välja parema juhusliku numbri genereerimise meetodi ja otsustada kuna viivitust rakendada