Security

#Authentication و Authorization و cookies و tokensAuthentication, authorization, cookies and tokens

معرفة إن caller سجّل دخول مش معناها يقدر يفتح أي invoice. AuthN بتثبت الهوية، و AuthZ بتقرر الوصول للعملية والـ resource. في API، الهوية الغايبة أو غير الصالحة غالباً 401، والهوية الصحيحة من غير صلاحية 403؛ أحياناً 404 مناسب عشان مانكشفش وجود resource.

Cookie آلية نقل وتخزين، و JWT صيغة token؛ مش متضادين. HttpOnly يمنع JavaScript يقرا cookie، لكنه مش بيمنع XSS يبعت requests باسم المستخدم.

#OAuth2 و OIDC والـ flows الحاليةOAuth 2.0, OIDC and current flows

OAuth 2.0 تفويض عميل للوصول لـ API بـ access token؛ مش login protocol لوحده. OIDC بيضيف هوية المستخدم و ID token للـ client. الـ API يستقبل access token المخصص له، مش ID token مخصص لواجهة تسجيل الدخول.

1. العميل يولّد code verifier عشوائي و S256 challenge، و state لربط الطلب بالرد.
2. المستخدم يسجل دخول عند identity provider عبر redirect URI مسجلة بدقة؛ OIDC يستخدم nonce لربط ID token بالطلب.
3. يرجع authorization code قصيرة العمر، والعميل يبدّلها مع verifier عبر token endpoint.
4. العميل يحقق OIDC response و ID token، ويستخدم access token لاستدعاء API. Refresh token مش مضمونة؛ تعتمد على scope وسياسة provider.

PKCE يحمي code interception، مش بديل عن state أو redirect validation. Confidential clients لسه محتاجة client authentication. Client credentials لـ service identity من غير مستخدم؛ فضّل managed identity أو certificates لما المنصة تدعم.

#JWT validation و refresh rotationJWT validation and refresh-token rotation

الـ signed JWT الشائعة فيها header و payload و signature. Base64Url مش encryption؛ ماتحطش أسرار في claims. التوقيع بيتحقق بمفاتيح issuer موثوق وخوارزميات مقبولة، مش بمجرد فك النص أو تصديق alg اللي المهاجم كاتبها.

// Package: Microsoft.AspNetCore.Authentication.JwtBearer 10.x
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = "https://identity.example.com"; // (1)
        options.Audience = "orders-api";
        options.MapInboundClaims = false;
        options.TokenValidationParameters = new()
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            RequireSignedTokens = true,
            ValidAlgorithms = [SecurityAlgorithms.RsaSha256], // (2)
            ClockSkew = TimeSpan.FromSeconds(30)
        };
    });
builder.Services.AddAuthorization();
// After builder.Build():
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/orders", () => Results.Ok()).RequireAuthorization(); // (3)

Access tokens قصيرة العمر تقلل نافذة السرقة، لكن مش فيه مدة سحرية واحدة. في offline validation الإلغاء مش فوري؛ denylist أو introspection يضيفوا state وتكلفة. Refresh rotation تستهلك token وتصدر بديل في عملية atomic، وتراقب reuse وتلغي family حسب سياسة provider. نسّق refresh المتوازي عشان ماتعتبرش retry شرعي سرقة بلا تحليل.

#ASP.NET Core Identity و passkeys في .NET 10ASP.NET Core Identity and .NET 10 passkeys

Identity بيدير users و password hashing و roles و lockout و email confirmation و recovery tokens. مش OAuth authorization server كامل، و bearer tokens بتاعة Identity API endpoints مش لازم تكون JWT ولا بديل عام لـ OIDC provider.

في ASP.NET Core 10، Identity فيها دعم passkeys عبر WebAuthn. وقت registration يتسجل public key، ووقت login authenticator يوقع challenge مربوط بالـ relying party و origin. البصمة أو PIN بتفتح استخدام المفتاح محلياً؛ السيرفر مش بيستلم البصمة أو private key.

1. سجّل challenge جديدة قصيرة العمر واربطها بالعملية والمستخدم عند اللزوم.
2. الـ browser و authenticator ينفذوا WebAuthn ceremony.
3. السيرفر يتحقق من challenge و origin و RP ID و signature و user verification حسب السياسة.
4. وفّر إدارة credentials وفقد الجهاز و recovery بمستوى أمان مناسب.

Passkeys بتقاوم phishing بسبب ارتباطها بالموقع، لكن recovery ضعيفة ممكن تهد الحماية. بعض credentials بتتزامن عن طريق مدير passkeys؛ ماتدعيش إن كل private key محبوسة في جهاز مادي واحد.

#Roles و claims و policies و resource authorizationRoles, claims, policies and resource authorization

Role زي Finance تصنيف واسع. Claim زي permission معلومة جاية من issuer موثوق. Policy تجمع requirements، و handler ينفذها. Resource-based authorization مناسبة لما القرار محتاج يعرف صاحب الطلب وحالته، مش هوية caller بس.

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("orders.edit", policy => policy
        .RequireAuthenticatedUser()
        .RequireClaim("permission", "orders.edit")); // (1)

// Endpoint fragment: tenant and user IDs come from validated identity context.
var order = await db.Orders.SingleOrDefaultAsync(
    o => o.Id == id && o.TenantId == tenantId, ct); // (2)
if (order is null) return Results.NotFound();
var decision = await authorization.AuthorizeAsync(
    user, order, "EditOwnPendingOrder");             // (3)
if (!decision.Succeeded) return Results.Forbid();
// Perform the update with concurrency protection.

المثال fragment مش تعريف كامل للـ handler. اربط كمان endpoint بسياسة permission، واقفل كل مسارات القراءة والكتابة والـ jobs والـ exports بنفس tenant boundary. EF Core filters مفيدة كـ defense in depth، بس raw SQL و IgnoreQueryFilters و admin paths محتاجين مراجعة. Cache keys و blob paths و message handlers لازم يعزلوا tenant برضه.

#OWASP Top 10:2025 وربطها بـ .NETOWASP Top 10:2025 mapped to .NET

دي قائمة توعية بالمخاطر، مش شهادة إن التطبيق آمن. الإصدار هنا 2025؛ SSRF ماعدتش category مستقلة زي 2021، لكنها لسه threat لازم تمنعها.

#SQL injection: افصل الداتا عن التنفيذSQL injection: separate data from executable syntax

لو username تدخل جوه SQL concatenation، المهاجم ممكن يغير معنى الـ query. Validation لوحدها مش بديل للـ parameters. EF LINQ عادة بتعمل parameterization للقيم، لكن raw SQL المبنية كسلسلة بتفضل خطر.

var sql = $"SELECT * FROM Users WHERE Email = '{email}'";
var users = await db.Users.FromSqlRaw(sql).ToListAsync(ct);

var users = await db.Users
    .Where(user => user.Email == email)
    .ToListAsync(ct);                                    // (1)

// If raw SQL is required, pass interpolation directly to FromSql:
var matches = await db.Users
    .FromSql($"SELECT * FROM Users WHERE Email = {email}") // (2)
    .ToListAsync(ct);

استخدم DB account بأقل صلاحيات. نفس المبدأ للـ shell: ماتركّبش commands من input؛ استخدم APIs و argument lists مع validation حسب العملية.

#XSS و CSRF: هجمات مختلفةXSS and CSRF: different attacks

XSS بتشغّل script في أصل موقعك، فتقدر تقرأ داتا أو تعمل أفعال المستخدم. Razor بيعمل HTML encoding افتراضياً، لكن Html.Raw مع user content أو DOM innerHTML خطر. Rich HTML محتاجة sanitizer موثوق، و JavaScript و URL contexts ليها قواعد encoding مختلفة.

@Html.Raw(Model.CustomerNote)

@Model.CustomerNote

CSRF بيستغل إن المتصفح بيبعت cookie تلقائي لموقعك لما المستخدم يزور صفحة مهاجم. استخدم antiforgery tokens في state-changing cookie-authenticated requests، و SameSite كطبقة إضافية؛ ماتعملش تغيير state بـ GET. CORS مش دفاع كامل ضد CSRF.

// MVC cookie-authenticated app; register before Build.
builder.Services.AddControllersWithViews(options =>
    options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute())); // (1)

// Razor form: the form tag helper normally generates this token already.
// Explicit generation is shown to make the mechanism visible.
// @Html.AntiForgeryToken()                                      // (2)

Content-Security-Policy دفاع إضافي ضد XSS، مش بديل للـ encoding. Bearer header اللي JavaScript بيضيفه صراحة أقل عرضة لـ CSRF التقليدي، لكن لو حطيت token في cookie رجع نفس نمط التهديد.

#SSRF: السيرفر مش proxy لأي URLSSRF: the server must not proxy arbitrary URLs

رابط صورة من المستخدم ممكن يبقى طلب لـ cloud metadata أو خدمة داخلية. فحص string بيبدأ بـ https مش كفاية: redirects و DNS rebinding و IPv6 و alternate IP formats يفتحوا مسارات تانية.

var bytes = await http.GetByteArrayAsync(userSuppliedUrl, ct);

builder.Services.AddHttpClient("product-images", client =>
    client.BaseAddress = new Uri("https://images.example.com/"))
    .ConfigurePrimaryHttpMessageHandler(() =>
        new HttpClientHandler { AllowAutoRedirect = false }); // (1)

// Endpoint fragment; imageId is a validated Guid, not a path or URL.
var client = clients.CreateClient("product-images");
using var response = await client.GetAsync(
    $"products/{imageId:N}", HttpCompletionOption.ResponseHeadersRead, ct); // (2)
response.EnsureSuccessStatusCode();

ضيف egress firewall أو proxy بسياسة منع private و loopback و link-local و metadata، و DNS controls، و timeouts وحد أقصى فعلي للـ streamed body حتى لو Content-Length غايب. لو business محتاج URLs حرة، محتاج validation للـ resolved destination وكل redirect واتصال، مش allowlist شكلية بس.

#Password hashing و encryption و HMACPassword hashing, encryption and HMAC

Hash عادي زي SHA-256 بصمة one-way للداتا، لكنه سريع زيادة لتخزين passwords. استخدم password hasher بطيء بملح عشوائي و work factor مناسب، زي Identity PBKDF2 أو مكتبة Argon2id موثوقة. Salt مش سر؛ بيمنع مشاركة الحساب المسبق بين المستخدمين، لكنه مش بيمنع تخمين password ضعيفة.

using Microsoft.AspNetCore.Identity;

var hasher = new PasswordHasher<IdentityUser>();
var storedHash = hasher.HashPassword(user, password);       // (1)
var result = hasher.VerifyHashedPassword(user, storedHash, suppliedPassword); // (2)
if (result == PasswordVerificationResult.SuccessRehashNeeded)
{
    // Persist a replacement hash through the user store after successful login.
}

ماتسجلش password أو hash في logs. تغيير work factor محتاج قياس على مواردك عشان hashing ماتتحولش لهجوم استنزاف.

#Secrets و Data Protection و dependency scanningSecrets, Data Protection and dependency scanning

Secrets في development من user-secrets، وهي مش encrypted vault. في production استخدم vault و workload identity عند الإمكان، مع صلاحيات محدودة و rotation. Environment variables اختيار نقل configuration لكنه مش مانع تسريب في dumps أو logs. سر اتعمله commit يتلغى ويتبدل فوراً؛ حذف الملف مش كفاية.

ASP.NET Core Data Protection بتحمي application state بـ encryption و integrity و purpose isolation و key rotation. الـ instances اللي بتشارك cookies محتاجة نفس application discriminator و key ring، مع تخزين دائم وحماية keys في السكون. مش Windows DPAPI، ومش بديل تلقائي لـ KMS لتشفير أرشيف عمره سنين.

using Microsoft.AspNetCore.DataProtection;

builder.Services.AddDataProtection().SetApplicationName("Shop"); // (1)
// Production: configure persistent shared keys and encryption at rest.

public sealed class ProtectedState(IDataProtectionProvider provider)
{
    private readonly IDataProtector _protector =
        provider.CreateProtector("checkout-state.v1");           // (2)
    public string Protect(string value) => _protector.Protect(value);
    public string Unprotect(string value) => _protector.Unprotect(value);
}

# .NET 10 SDK form; include indirect dependencies too.
dotnet package list --vulnerable --include-transitive
# Older SDK form:
dotnet list package --vulnerable --include-transitive

تشغيل vulnerability list مش معناه CI هتفشل تلقائياً حسب سياستك؛ افحص النتيجة أو configure NuGet audit severities وفشل warnings المطلوبة. راجع transitive dependencies ومصدر package والـ advisory وخطة التحديث، مع exceptions محدودة ومؤرخة.

#HTTPS و headers و webhook verificationHTTPS, security headers and webhook verification

HTTPS يحمي النقل، و HSTS يقول للمتصفح يستخدم HTTPS في الزيارات القادمة ضمن السياسة؛ مش بديل عن TLS ولا بيحمي أول زيارة من غير preload. وراء proxy، اضبط forwarded headers من proxies موثوقة قبل HTTPS redirection. استخدم CSP للمصادر، و frame-ancestors ضد framing، و X-Content-Type-Options: nosniff، و Referrer-Policy مناسبة؛ اختبر السياسة بدل نسخ headers عمياني.

Webhook مش موثوقة لأنها بتقول payment succeeded. تحقق من signature على raw bytes قبل parsing، واربط timestamp بالـ signature حسب بروتوكول provider لمنع replay، وبعدها تحقق من order و amount و currency و idempotency.

using System.Security.Cryptography;

// Illustrative provider contract: hex HMAC-SHA256 over the exact raw body.
static bool Verify(byte[] rawBody, string signatureHex, byte[] secret)
{
    if (signatureHex.Length != 64) return false;             // (1)
    byte[] supplied;
    try { supplied = Convert.FromHexString(signatureHex); }
    catch (FormatException) { return false; }
    byte[] expected = HMACSHA256.HashData(secret, rawBody);   // (2)
    return CryptographicOperations.FixedTimeEquals(expected, supplied); // (3)
}

المثال مش بيمنع replay لوحده؛ محتاج timestamp موثوق ونافذة زمنية و event ID فريدة متخزنة atomic مع الـ effect أو inbox. قارن المبلغ والعملة بالـ order من database، وماتثقش في client redirect كإثبات دفع.