In articolul de azi iti voi vorbi de cele mai intalnite modalitati de atacare a site-urilor web si cum facem in ASP.NET Core sa blocam astfel de atacuri. Pentru doi si ani jumatate am lucrat in devizia de programatori a unei mari banci, iar securitatea era intotdeanu pusa pe primul plan. Inca tin minte cum Product Owner-ul nostru, un maghiar simpatic, mereu ne zicea ca mai intai securitatea si pe urma restul. Lunar se faceau tot felul de teste pentru a sparge aplicatia, iar oamenii de la audit erau foarte urati. Dar in acea perioada am invatat cel mai mult despre securitate si mi-am dat seama si eu ca oamenii aia au dreptate.
Acesta este cel mai popular atac in randul hackerilor si functioneaza in felul urmator. Aplicatia web primeste de la client un string pe care il concateneaza direct cu scriptul sql, permitand atacatorului sa trimita si cod sql.
string select = "select * from dbo.CATEGORIES where CATEGORY_NAME='" + categoryName + "'";
using (SqlConnection sqlConnection = new SqlConnection(connectionString))
{
sqlConnection.Open();
using (SqlCommand sqlCommand = new SqlCommand(select, sqlConnection))
{
SqlDataReader reader = sqlCommand.ExecuteReader();
while (reader.Read())
{
Console.WriteLine(reader.GetString(1));
}
}
}
Codul de mai sus este vulnerabil atacurilor sql, deoarece parametrul category name este concatenat direct, fara nicio verificare, atacatorul putand pune cod SQL.
Cele mai uzuale modalitati de a te proteja de astfel de atacuri sunt sa folosesti un ORM precum EntityFramework sau sa folosesti proceduri stocate in care nu concatenezi scripturi pe care sa le executi direct din procedura (deci nu folosi sp_executesql fara cap).
Astea sunt niste atacuri imputite, pentru ca hackerul se poate ascunde foarte bine si sa produca pagube. Acest atac functioneaza in felul urmator. Utilizatorul se autentifica in aplicatia ta bancara, iar tu ii returnezi un cookie, cu care se va autentifica in sesiunea curenta. Dar sa zicem ca fix in accea sesiune (la unele site-uri cookie-ul expira intr-un an, deci bafta), utilizatorul intra pe un site unde da click pe un buton, care face parte din acest formular
<h1>Congratulations! You have won a car!</h1>
<form action="http://your-website.com/api/account" method="post">
<input type="hidden" name="Address" value="[email protected]">
<input type="hidden" name="Amount" value="99999">
<input type="submit" value="Click here for all details">
</form>
Pai fix atunci se trimite un request pe aplicatia ta bancara si cere sa faca o plata catre o adresa, o plata neautorizata.
Pentru a rezolva aceasta problema mai ti minte tu atributul ala ValidateAntiForgeryToken, ala te salveaza de probleme. Practic in formular se mai pune un field hidden cu un key, care este validat la post, daca cererea nu are acel token, nu va fi acceptata.
Sa nu scrii niciodata actiuni care sa arate asa:
public IActionResult Login(string redirectUrl)
{
//Login logic
return Redirect(redirectUrl);
}
De ce, pai sa zicem ca hack-ul ii da unui om link-ul catre site-ul tau ca sa se logheze astfel:
https://yourgoodsite.com?returnUrl=hackersite.com
Utilizatorul se logheaza pe site-ul tau, vede chiar si lacatul de ssl si se gandeste ca totul este in regula. Doar ca imediat dupa login este redirectionat catre site-ul hacker-urului.
Folosind metoda LocalRedirect(redirectUrl). Aceasta metoda arunca o exceptie daca link-ul nu este local.
Sa zicem ca nu ai ssl pentru site-ul tau, iar utilizatorul se autentifica dintr-o retea publica. Ghici cine are acces la credentialele sale? Un hacker de cartier. Practic ssl cripteaza conexiunea intre site si client.
PS: Mai sunt multe altele si trebuie sa le stii mai mereu. De ce ? pentru ca hackerii invata si ei, de obicei chiar mai repede decat restul. Asa ca mai citeste inca o data articolul si pe urma cauta despre XSS (Cross Site Scripting)