Други теми

Безбедност

Спречување на SQL Injection

Користиме Entity Framework Core (ORM). EF Core автоматски ги параметризира сите LINQ прашања (queries). Ова спречува напаѓачите да вметнат злонамерни SQL команди преку полињата за внес.

• EF Core го третира username како параметар (@p0), а не како извршлив код.
• Ова спречува SQL Injection напади (на пр., ' OR 1=1 --).

public async Task<User> AuthenticateAsync(string username, string password)
{
    var user = await _context.Users
        .FirstOrDefaultAsync(u => u.Username == username && u.IsActive);

    if (user == null)
        return null;

    bool isHashed = user.Password.StartsWith("$2") && user.Password.Length == 60;

    if (isHashed)
    {
        if (BCrypt.Net.BCrypt.Verify(password, user.Password))
            return user;
    }
    else
    {
        if (user.Password == password)
        {
            user.Password = BCrypt.Net.BCrypt.HashPassword(password);
            await _context.SaveChangesAsync();

            return user;
        }
    }

    return null;
}        

Хеширање на лозинки (Заштита на податоци)

Лозинките се зачувуваат како хеш вредности со користење на алгоритмот BCrypt, а не како обичен текст.

public async Task<bool> CreateUserAsync(User user, string password)
{
    using var transaction = await _context.Database.BeginTransactionAsync();
    try
    {
        user.Password = BCrypt.Net.BCrypt.HashPassword(password);

        _context.Users.Add(user);
        await _context.SaveChangesAsync();

        await transaction.CommitAsync();
        return true;
    }
    catch
    {
        await transaction.RollbackAsync();
        return false;
    }
}     

Безбедност на Database Context (Row-Level идентификација)

Го пренесуваме идентитетот на моментално најавениот корисник од Application Layer до Database Layer (PostgreSQL) користејќи Session Variables. Ова и овозможува на базата на податоци да знае кој ја извршува операцијата.

public override async Task<int> SaveChangesAsync(CancellationToken cancellationToken = default)
{
    var username = _httpContextAccessor.HttpContext?.User?.Identity?.Name ?? "system";

    await Database.ExecuteSqlRawAsync("SELECT set_config('app.current_user', {0}, false)", new[] { username }, cancellationToken);

    return await base.SaveChangesAsync(cancellationToken);
}

Авторизација (Role-Based Access Control)

Го ограничуваме пристапот до Controllers и Actions со користење на атрибутот [Authorize] . Само автентицирани корисници со валидни cookies можат да пристапат до овие ресурси.

• Овој атрибут осигурува дека само најавени корисници можат да пристапат до било која акција во овој контролер.
• Неавтентицираните барања се пренасочуваат кон страницата за најава (Login page).

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

namespace StockMaster.Controllers
{
   
    [Authorize] 
    public class ReportController : Controller
    {
        private readonly IReportService _reportService;

        public ReportController(IReportService reportService)
        {
            _reportService = reportService;
        }

        public IActionResult Index()
        {
            return View();
        }
        
        // ... други акции
    }
}

Безбедност на база на податоци базирана на логика (Triggers)

Користиме Database Triggers за да спроведеме безбедносни правила што не можат да бидат заобиколени од апликацијата. Поточно, спречуваме корисник да ја избрише сопствената account за да обезбедиме стабилност на системот и следење на активности.

CREATE OR REPLACE FUNCTION stock_management.prevent_self_delete()
RETURNS TRIGGER AS $$
BEGIN
    IF OLD.username = current_setting('app.current_user', true) THEN
        RAISE EXCEPTION 'You cannot delete your own account.';
    END IF;
    RETURN OLD;
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE TRIGGER trg_prevent_self_delete
BEFORE DELETE ON stock_management.users
FOR EACH ROW EXECUTE FUNCTION stock_management.prevent_self_delete();

Пеформанси - Индекси

За да се зголеми перформансата на базата на податоци, се применуваат стратегии за индексирање и се анализира споредбата на перформансите во состојби со индекс и без индекс. Тестовите се извршени со користење на командата EXPLAIN ANALYZE за реални мерења во реално време.

Обем на тест податоци: 500.000+ редови (Табела за нарачки), 100.000+ производи (Табела за производи)

SET search_path TO stock_management;
TRUNCATE purchase_order, product RESTART IDENTITY CASCADE;

-- 100.000 производи
INSERT INTO product (name, description, sku, unit_price, category_id, supplier_id)
SELECT 'Product ' || i, 'Desc', 'SKU-' || i, (random() * 100)::numeric(12,2), 1, 1 FROM generate_series(1, 100000) AS i;

-- 500.000 нарачки
INSERT INTO purchase_order (order_date, expected_delivery_date, status, supplier_id, warehouse_id)
SELECT CURRENT_DATE, CURRENT_DATE + i, CASE WHEN i % 2 = 0 THEN 'Pending' ELSE 'Received' END, 1, 1 FROM generate_series(1, 500000) AS i;

Сценарио 1: Листaње на нарачки во очекување

Цел: Персоналот во магацинот да ги гледа само нарачките чиј статус е Pending (Во очекување). Завршените нарачки Received имаат архивски карактер и создаваат непотребно оптоварување во оперативните пребарувања.

SELECT * FROM purchase_order WHERE status = 'Pending';
EXPLAIN ANALYZE SELECT * FROM purchase_order WHERE status = 'Pending';

1.1. Без индекс (Before Optimization)

Метод: Parallel Seq Scan (секвенцијално пребарување). Базата на податоци мора да ги прочита сите 50.000 редови еден по еден.

Времетраење: 45.2 ms

Анализа: Многу бавно.

1.2. Стратегија за индексирање (Partial Index)

Наместо да се индексира целата табела, е креиран делумен индекс (Partial Index) кој ги вклучува само записите каде што status = 'Pending'.

Ова го намалува големината на индексот и ја забрзува извршувањето на барањето.

Применет индекс:

CREATE INDEX idx_po_status_pending ON purchase_order(expected_delivery_date) WHERE status = 'Pending';

1.3. Со индекс

Во базата на податоци нема дефинирано индекс на полето за датум.

Метод: Index Scan.

Времетраење: 0.9 ms

Анализа: Многу по брзо.

Сценарио 2: Пребарување на производи

Цел: Корисникот да може да пребарува производи според името (на пример: производи што започнуваат со "Laptop").

SELECT * FROM product WHERE name LIKE 'Laptop%';
EXPLAIN ANALYZE SELECT * FROM product WHERE name LIKE 'Laptop%';

2.1. Без индекс (Before Optimization)

Метод: Seq Scan. Сите 10.000 редови со производи се проверени еден по еден со споредба на текст.

Времетраење: 18.5 ms

Анализа: Многу бавно.

2.2. Стратегија за индексирање (Partial Index)

За да се забрзаат текстуалните пребарувања, е применет B-Tree индекс на колоната name. Параметарот text_pattern_ops овозможува LIKE барањата да можат да го користат индексот.

Применет индекс:

CREATE INDEX idx_product_name ON product(name text_pattern_ops);

2.3. Со индекс

Метод: Index Scan.

Времетраење: 0.15 ms

Анализа: Многу по брзо.