အခန်း ၁၄ :: Security

Security ဆိုတာ Software ရဲ့ "Feature" မဟုတ်ပါဘူး။ "Attribute" (အရည်အသွေး) တစ်ခု ဖြစ်ပါတယ်။

အိမ်ဆောက်ပြီးမှ သော့ခတ်ဖို့ စဉ်းစားတာမျိုး မဟုတ်ဘဲ၊ အိမ်ပုံစံ Design ဆွဲကတည်းက ဘယ်နားမှာ တံခါးတပ်မယ်၊ ခြံစည်းရိုး ဘယ်လိုခတ်မယ် ဆိုတာ စဉ်းစားရသလိုပါပဲ။

ဒါကို "Security by Design" လို့ ခေါ်ပါတယ်။

အရင်တုန်းကတော့ Development ပြီးမှ Security Team က ဝင်စစ်ကြလေ့ရှိပါတယ်။ အဲဒီလို နောက်ကျမှ စစ်လို့ အမှားတွေ့ရင်၊ အစကနေ ပြန်ပြင်ရတာတွေ ဖြစ်တတ်ပါတယ်။ ကုန်ကျစရိတ် အရမ်းများပါတယ်။

ဒါကြောင့် ဒီနေ့ခေတ်မှာ DevSecOps (Development + Security + Operations) ဆိုပြီး Security ကို အစောဆုံး အဆင့်တွေ (Planning/Coding) မှာကတည်းက ထည့်သွင်းစဉ်းစားလာကြပါပြီ။ ဒါကို "Shift Left" လို့ ခေါ်ပါတယ်။ (Timeline ရဲ့ ဘယ်ဘက် အစွန်းကို ရွှေ့လိုက်တဲ့ သဘောပါ)။

Security ရဲ့ အဓိက တိုင်ကြီး ၃ တိုင် (CIA Triad) ကတော့-

1. Confidentiality: လျှို့ဝှက်သင့်တာ လျှို့ဝှက်ရမယ်။ (Password တွေ သူများ မမြင်ရဘူး)

2. Integrity: Data တွေ မမှန်မကန် ပြင်ဆင်ခံရတာ မရှိစေရဘူး။ (Bank Money Transfer လုပ်ရင် ပမာဏ အတိအကျ ရောက်ရမယ်)

3. Availability: System က အမြဲတမ်း သုံးလို့ ရနေရမယ်။ (Thai ဘက် က Data Center မီးပျက်သွားလို့ , ငလျင်ထိသွားလို့ စသည့် အကြောင်းပြချက်တွေ server တစ်ခု ကျသွားတာနှင့် System ကျသွားတာမျိုး မဖြစ်ရဘူး)

၁၄.၁ Fundamental Principles of Secure Design

Code မရေးခင် Developer တိုင်း သိထားရမယ့် ရွှေရောင်စည်းမျဉ်း (Golden Rules) တွေ ရှိပါတယ်။

၁. Principle of Least Privilege (PoLP)

User တစ်ယောက် (သို့) Service တစ်ခုကို "လိုအပ်သလောက် အနည်းဆုံး" လုပ်ပိုင်ခွင့်ပဲ ပေးရပါမယ်။

• Bad Practice: Junior Developer တစ်ယောက်က Production မှာ App DB ရဲ့ user role ကို root access သုံးထားတာ။ (မှားဖျက်မိရင် ဒုက္ခအကြီးကြီး ရောက်သွားနိုင်တယ်)

• Good Practice: Application တစ်ခုအတွက် DB User ဆောက်ရင် SELECT, INSERT, UPDATE လောက်ပဲ ပေးထားမယ်။ DROP TABLE ပေးမထားဘူး။ ဒါဆိုရင် App က SQL Injection မိလို့ Hacker ဝင်မွှေရင်တောင်၊ Table ကြီးတစ်ခုလုံး ဖျက်ပစ်လို့ မရတော့ဘူး။ Damage Control လုပ်နိုင်သွားတယ်။

၂. Defense in Depth (အလွှာလိုက် ကာကွယ်ခြင်း)

လုံခြုံရေးကို တစ်နေရာတည်းမှာ ပုံအောမထားပါနဲ့။ ရဲတိုက်တစ်ခုလိုပါပဲ။ ကျုံး ရှိမယ်၊ မြို့ရိုး ရှိမယ်၊ တံခါးစောင့် ရှိမယ်၊ အတွင်းဆောင် ရှိမယ်။ တစ်နေရာ ပေါက်တာနဲ့ အကုန်ပါသွားတာမျိုး မဖြစ်ရပါဘူး။

sequenceDiagram

    autonumber

    participant Attacker as Client/Attacker

    participant FW as Firewall

    participant WAF as WAF

    participant App as App (Auth & Validation)

    participant DB as Database (Encryption)

    Attacker->>FW: 1. Incoming Request

    Note right of FW: Layer 1: Network Security

    FW->>WAF: 2. Allowed Ports/IPs

    Note right of WAF: Layer 2: Web Protection

    WAF->>App: 3. Clean Request

    Note right of App: Layer 3 & 4: Auth & Input Validation

    App->>DB: 4. Query

    Note right of DB: Layer 5: Data Encryption

    DB-->>App: Data

    App-->>Attacker: Response

၃. Secure Defaults

System စစချင်း Install လုပ်လိုက်တာနဲ့ Default အနေအထားက လုံခြုံနေရမယ်။

• Bad: Default password admin:admin ပေးထားတာ။

• Good: ပထမဆုံး Login ဝင်ရင် Password မပြောင်းမနေရ (Force Change) လုပ်ခိုင်းတာ။ အန္တရာယ်ရှိနိုင်တဲ့ Feature တွေကို Default မှာ OFF ထားတာ။

၄. Separation of Duties (တာဝန်ခွဲဝေခြင်း)

သော့ကို တစ်ယောက်တည်း ကိုင်မထားရပါဘူး။

• Dev vs Ops: Developer က Code ရေးမယ်။ Production Server ကို ဝင်မပြင်သင့်ဘူး။ Production ကို Deploy လုပ်တာကို CI/CD Pipeline (သို့) Ops Team ကပဲ လုပ်သင့်တယ်။ ဒါမှ Developer အကောင့် ပါသွားရင်တောင် Production မပျက်စီးမှာ။

၅. Fail Securely

System Error တက်သွားရင် "တံခါးပိတ်လျက်" (Closed) အနေအထားနဲ့ ပျက်ရပါမယ်။

• Scenario: Login System Error တက်သွားတယ်။ User ကို ဝင်ခွင့် ပေးလိုက်မလား (Fail Open)၊ တားလိုက်မလား (Fail Closed)။

• Answer: လုံးဝ တားထားရမယ်။ Error Message မှာလည်း "Database Connection Failed" ဆိုပြီး အရှည်ကြီး မပြရဘူး။ "Something went wrong" လောက်ပဲ ပြရမယ်။ Hacker ကို သဲလွန်စ မပေးရဘူး။

၆. Minimize Attack Surface

ရန်သူ ဝင်လာနိုင်တဲ့ အပေါက်တွေကို အတတ်နိုင်ဆုံး ပိတ်ထားရမယ်။

• မလိုအပ်တဲ့ Port တွေ ပိတ်ထား။ (MySQL Port 3306 ကို အစား အခြား port number သုံးခြင်း။ Public သုံးခွင့်မပေးပဲ private network ကနေပဲ သုံးခွင့်ပေးခြင်း။)

• မသုံးတော့တဲ့ Library တွေ၊ Feature အဟောင်းတွေ ဖြုတ်ပစ်။ Code များလေ၊ Bug ပါနိုင်လေ၊ Hacker ဝင်ပေါက် များလေပါပဲ။

၇. Keep Security Simple

Complexity က Security ရဲ့ ရန်သူပါ။ System ရှုပ်ထွေးလေ၊ အမှားပါလာနိုင်လေပါပဲ။ လုံခြုံရေး စနစ်တွေကို ရိုးရှင်းပြီး စစ်ဆေးရ လွယ်ကူအောင် (Auditable) ထားသင့်ပါတယ်။

၁၄.၂ Data Protection Essentials: Encoding, Encryption vs Hashing

Software Engineer တစ်ယောက်အနေနဲ့ ဒီ ၃ ခုကို လုံးဝ (လုံးဝ) ရောထွေးလို့ မရပါဘူး။

Data ကို ပုံစံပြောင်းတာခြင်း တူပေမယ့်၊ ရည်ရွယ်ချက် တွေက မတူညီပါဘူး။

graph TD

    subgraph Encoding

    A[Data] -->|Base64| B[Encoded Data]

    B -->|Base64| A

    end

    subgraph Encryption

    C[Data] -->|Key| D[Encrypted Data]

    D -->|Key| C

    end

    subgraph Hashing

    E[Data] -->|One Way| F[Hash Value]

    F -.->|Cannot Reverse| E

    end

၁. Encoding (Not Security!)

Data ကို သယ်ယူပို့ဆောင်ရ လွယ်ကူအောင် format ပြောင်းတာ သက်သက်ပါပဲ။ Security လုံးဝ မရှိပါဘူး။

Base64 နဲ့ Encode ထားတဲ့ စာကို ဘယ်သူမဆို Decode လုပ်ပြီး ဖတ်လို့ ရပါတယ်။

• Use Case: binary image data တွေကို text string အဖြစ် ပြောင်းပြီး JSON ထဲ ထည့်ပို့ချင်တဲ့အခါမျိုးမှာ သုံးပါတယ်။ Password တွေကို ဖွက်ဖို့ ဘယ်တော့မှ မသုံးရပါဘူး။

၂. Encryption (Confidentiality)

Data ကို "သော့" (Key) ရှိ မှပဲ ဖတ်လို့ရအောင် ဝှက်ထားတာပါ။ သော့ရှိရင် ပြန်ဖွင့် (Decrypt) လို့ ရပါတယ်။

နှစ်မျိုး ရှိပါတယ်။

A. Symmetric Encryption (House Key Role)

သော့တစ်ချောင်းတည်း (Shared Key) ကို သုံးပြီး ပိတ်တာရော၊ ဖွင့်တာရော လုပ်တာပါ။ အိမ်တံခါးသော့လိုပါပဲ။ ဝင်တုန်းကလည်း ဒီသော့၊ ထွက်တော့လည်း ဒီသော့နဲ့ပဲ ဖွင့်ရတာပါ။

Standard vs AEAD (Authenticated Encryption)

အရင်တုန်းက AES-CBC mode ကို သုံးခဲ့ကြပေမယ့်၊ သူက Data ကိုပဲ ဝှက်ပေးနိုင်ပြီး (Confidentiality)၊ Data ကို လမ်းမှာ Hacker က ပြင်လိုက်ရင် မသိနိုင်ပါဘူး (No Integrity)။

ဒါကြောင့် ဒီနေ့ခေတ်မှာ AEAD (Authenticated Encryption with Associated Data) ဖြစ်တဲ့ AES-GCM သို့မဟုတ် ChaCha20-Poly1305 ကို မဖြစ်မနေ သုံးရပါမယ်။

Why AEAD? (Confidentiality + Integrity)

AEAD algorithm တွေက Encrytion လုပ်တဲ့အခါမှာ Authentication Tag တစ်ခုပါ တွဲထုတ်ပေးပါတယ်။

Data ကို Decrypt လုပ်တဲ့အခါ၊ အဲဒီ Tag ကို အရင်စစ်ပါတယ်။ Tag ကိုက်ညီမှသာ Data ကို Decrypt လုပ်ပေးပါတယ်။

ဒါကြောင့် Hacker က Encrypted Data ကို တစ်လုံးပဲ ပြင်လိုက်ရင်တောင် Tag မကိုက်တော့တဲ့အတွက် Decryption process က ချက်ချင်း Fail ဖြစ်သွားပြီး မှားယွင်းတဲ့ Data ထွက်လာမှာကို ကာကွယ်ပေးနိုင်ပါတယ်။

• Algorithm: AES-256-GCM (Hardware support ရှိရင် သုံးပါ), ChaCha20-Poly1305 (Mobile devices တွေအတွက် ပိုမြန်တယ်)။

sequenceDiagram

    participant Sender

    participant Receiver

    Note over Sender, Receiver: Shared Secret Key (Key)

    Sender->>Sender: Encrypt(Key, Msg) -> Ciphertext + AuthTag

    Sender->>Receiver: Send (Ciphertext, AuthTag)

    Receiver->>Receiver: Verify Integrity (AuthTag)

    alt Tag Matches

        Receiver->>Receiver: Decrypt -> Message

    else Tag Mismatch

        Receiver->>Receiver: REJECT (File Corrupted/Tampered)

    end

B. Asymmetric Encryption (Mailbox Role)

Key နှစ်ချောင်း သုံးပါတယ်။ Public Key (လူတိုင်းကို ပေးထားလို့ ရတယ်) နဲ့ Private Key (ကိုယ်တစ်ယောက်တည်း သိမ်းထားရမယ်)။

စာတိုက်ပုံး (Mailbox) လိုပါပဲ။ စာထည့်တဲ့ အပေါက် (Public Key) ကနေ ဘယ်သူမဆို စာလာထည့်လို့ ရတယ်။ ဒါပေမယ့် စာတိုက်ပုံးကို ဖွင့်ပြီး စာဖတ်ဖို့ (Decrypt) အတွက်တော့ သော့ (Private Key) ရှိတဲ့ ပိုင်ရှင်ပဲ လုပ်လို့ ရပါတယ်။

• Algorithm: RSA, ECC.

• Use Case: HTTPS (TLS) စစချင်း ချိတ်ဆက်တဲ့ နေရာ (Key Exchange) မှာ သုံးပါတယ်။

sequenceDiagram

    participant Alice

    participant Bob

    Note over Bob: Bob has Key Pair:<br/>Private Key (secret)<br/>Public Key (shared)

    Bob->>Alice: 1. Share Public Key

    Note over Alice: Alice encrypts message<br/>with Bob's Public Key

    Alice->>Bob: 2. Send Encrypted Message

    Note over Bob: Bob decrypts with<br/>his Private Key

    Note over Bob: Only Bob can read!

၃. Hashing (Integrity)

Data ကို ကြိတ်ချေပြီး ပုံစံပြောင်းလိုက်တာပါ။ မူရင်း Data ကို ပြန်ပြောင်းယူလို့ (Reverse) လုံးဝ မရပါဘူး။ (One-way Function)။

ကြက်ဥကို မွှေလိုက်သလိုပါပဲ။ Omelet ဖြစ်သွားပြီးရင် ကြက်ဥ အလုံးလိုက် ပြန်ရဖို့ မဖြစ်နိုင်တော့ပါဘူး။

• Password သိမ်းတဲ့အခါ Hashing သုံးရပါမယ်။ Encryption မသုံးရဘူး။ ဘာလို့လဲဆိုတော့ Admin ကိုယ်တိုင်တောင် User ရဲ့ Password ကို မသိသင့်လို့ပါပဲ။ User Login ဝင်ရင် သူရိုက်လိုက်တဲ့ Password ကို Hash လုပ်၊ Database ထဲက Hash နဲ့ တိုက်စစ်။ တူရင် ပေးဝင်လိုက်ရုံပါပဲ။

• Algorithm: MD5, SHA-1 တွေက ဟောင်းသွားပါပြီ (Crack လို့ လွယ်ပါတယ်)။ bcrypt, Argon2 တို့ကို သုံးရပါမယ်။ သူတို့မှာ Salt (Random Data) ပါ ထည့်ပေါင်းထားလို့ Rainbow Table နဲ့ တိုက်ခိုက်တာကို ခံနိုင်ရည် ရှိပါတယ်။

၁၄.၃ Threat Modeling: ရန်သူ့နေရာမှ တွေးကြည့်ခြင်း

Threat Modeling ဆိုတာ Code မရေးခင်ကတည်းက "ငါသာ Hacker ဆိုရင် ဒီ System ကို ဘယ်လိုဖောက်မလဲ" ဆိုပြီး ကြိုတွေးတာပါ။

Microsoft ရဲ့ STRIDE Model က အကျော်ကြားဆုံးပါပဲ။

၁၄.၄ OWASP Top 10: Web ပေါ်က အန္တရာယ်ကောင်များ

OWASP (Open Web Application Security Project) ဆိုတာ Web Security အတွက် စံသတ်မှတ်ပေးတဲ့ အဖွဲ့အစည်းပါ။ သူတို့က ၂-၃ နှစ်တစ်ခါ "Top 10 Vulnerabilities" (အဖြစ်အများဆုံး အားနည်းချက် ၁၀ ခု) ကို ထုတ်ပြန်ပါတယ်။ ၂၀၂၅ စာရင်းအရ အရေးကြီးဆုံးတွေကို ကြည့်ရအောင်။

၁. Broken Access Control (ဝင်ခွင့် မှားယွင်းခြင်း)

အဖြစ်အများဆုံးနဲ့ အန္တရာယ်အများဆုံးပါ။ Login ဝင်ထားပေမယ့်၊ ကိုယ်မပိုင်တဲ့ Data တွေကို ဝင်ကြည့်လို့ ရနေတာမျိုးပါ။

• Scenario (IDOR): user/101 က URL ကို user/102 လို့ ပြောင်းလိုက်တာနဲ့ တခြားလူရဲ့ Profile ကို မြင်နေရတာ။

• Mitigation: Code ထဲမှာ IF (current_user.id == requested_data.owner_id) ဆိုတဲ့ Logic ကို Database Query တိုင်းမှာ မဖြစ်မနေ ထည့်စစ်ရပါမယ်။

၂. Cryptographic Failures (လျှို့ဝှက်ချက် ပေါက်ကြားခြင်း)

Password တွေကို Plain text (စာသားအတိုင်း) သိမ်းတာ၊ Encryption Key တွေကို Git ထဲ တင်မိတာတွေပါ။

• Mitigation: Password ဆို bcrypt နဲ့ Hash လုပ်။ Data ဆို AES-256 နဲ့ Encrypt လုပ်။ HTTPS (TLS) မရှိဘဲ ဘာ Data မှ မပို့နဲ့။

၃. Injection (SQL Injection & Others)

User ဆီက Input ကို မစစ်ဆေးဘဲ Database ထဲ တိုက်ရိုက် ထည့်သုံးလိုက်တာပါ။

• Injection Example: SELECT * FROM users WHERE name = ' + userInput + ';

• Hacker က userInput နေရာမှာ ' OR '1'='1 လို့ ရိုက်လိုက်ရင်၊ Query က SELECT * FROM users WHERE name = '' OR '1'='1' ဖြစ်သွားပြီး User အားလုံးရဲ့ Data တွေ ထွက်လာပါလိမ့်မယ်။

• Mitigation: Parameterized Queries (Prepared Statements) ကိုပဲ သုံးပါ။ ORM (Object Relational Mapping) တွေက ဒါကို အလိုအလျောက် ကာကွယ်ပေးပါတယ်။

၄. Insecure Design

Code အမှား မဟုတ်ဘဲ၊ Design ကတည်းက လုံခြုံရေး မစဉ်းစားခဲ့တာပါ။

• Example: Password Reset လုပ်ရင် "Security Question" မေးတာ။ (အဖြေက Facebook မှာ ရှာရင် တွေ့နိုင်တယ်)။ အဲဒီအစား Email/SMS OTP သုံးတာက Design အရ ပိုလုံခြုံပါတယ်။

၅. Security Misconfiguration

Default Password မပြောင်းတာ၊ Error Message မှာ Stack Trace တွေ အကုန်ပြတာ၊ Cloud Bucket (S3) ကို Public ဖွင့်ထားမိတာတွေပါ။

• Tip: Production ကို Deploy မလုပ်ခင် "Security Checklist" နဲ့ အမြဲ စစ်ပါ။

၁၄.၅ Cryptography & Secrets Management: လျှို့ဝှက်ချက်များ ထိန်းသိမ်းခြင်း

Rule #1: Never Write Your Own Crypto

ဒါအရေးအကြီးဆုံး ပါပဲ။ ကိုယ့်ဘာသာ Encryption Algorithm တွေ လျှောက်မရေးပါနဲ့။

သင်ရေးတဲ့ Code ဟာ Hacker တွေအတွက် စက္ကန့်ပိုင်းနဲ့ ဖောက်လို့ ရနိုင်ပါတယ်။ ကမ္ဘာကျော် Cryptographer တွေ စမ်းသပ်ထားတဲ့ Library တွေကိုပဲ သုံးပါ။ (e.g., OpenSSL, libsodium, Bcrypt)။

Secrets Management (သော့ကို ဘယ်မှာ သိမ်းမလဲ)

API Keys, Database Passwords တွေကို Source Code ထဲမှာ Hardcode လုံးဝ မလုပ်ရပါဘူး။

Git ထဲပါသွားရင် ပြဿနာ အကြီးကြီး တက်ပါပြီ။

• DON'T: const apiKey = "sk-123456789";

• DO: Environment Variable သုံးပါ။ process.env.API_KEY

Production မှာဆိုရင် AWS Secrets Manager, HashiCorp Vault လိုမျိုး Dedicated Secret Store တွေကို သုံးတာ အကောင်းဆုံးပါပဲ။

.env ഫile တွေကိုလည်း .gitignore ထဲ ထည့်ဖို့ မမေ့ပါနဲ့။

၁၄.၆ The Myth of Client-Side Security

Software Engineer တစ်ယောက် မှတ်ထားရမှာက "Client (Phone/Browser) ပေါ် ရောက်သွားတဲ့ Code မှန်သမျှဟာ Public ဖြစ်သွားပြီ" ဆိုတာပါပဲ။

Mobile Apps & Frontend are "Transparent"

App ကို Build လုပ်လိုက်ရင် Binary ဖြစ်သွားလို့ ဖတ်မရတော့ဘူးလို့ မထင်ပါနဲ့။ Decompile လုပ်ပြီး Source Code ပြန်ဖတ်လို့ ရနိုင်သလို၊ Network Traffic ကို ကြားဖြတ်ဖတ်ပြီး API Key တွေ ခိုးလို့ ရပါတယ်။

ဒါကြောင့် Secret Key တွေကို Frontend/Mobile App ထဲ ဘယ်တော့မှ မထည့်ရပါဘူး။

The Solution: BFF Pattern (Backend for Frontend)

OpenAI API Key လိုမျိုး Secret တွေကို Backend Server ပေါ်မှာပဲ ထားပါ။ Mobile App က ကိုယ့် Backend ကို လှမ်းခေါ်၊ Backend ကမှတဆင့် OpenAI ကို Key နဲ့ လှမ်းခေါ်။ ဒါဆိုရင် Secret Key က Server ပေါ်မှာပဲ ရှိနေလို့ လုံခြုံပါတယ်။

အမှား (Insecure): Mobile App ထဲမှာ Key ထည့်ထားတာ။ Hacker က Decompile လုပ်ပြီး Key ကို ယူသွားနိုင်တယ်။

flowchart LR

    subgraph Client["Client (Mobile/Web)"]

        A[App with<br/>API Key]

    end

    subgraph Third["Third Party Service"]

        B[OpenAI / Stripe]

    end

    A -->|"API Key exposed<br/>in app code"| B

    subgraph Hacker["Hacker"]

        H[Decompile App<br/>Extract API Key]

    end

    Client -.->|"Key ခိုးယူနိုင်"| Hacker

    Hacker -.->|"စိတ်ကြိုက်သုံးစွဲ"| Third

အမှန် (Secure): Proxy ခံသုံးတာ။

flowchart LR

    subgraph Client["Client (Mobile/Web)"]

        A[App<br/>No API Key]

    end

    subgraph Backend["Your Backend Server"]

        B[API Key<br/>stored securely]

    end

    subgraph Third["Third Party Service"]

        C[OpenAI / Stripe]

    end

    A -->|"1. Request<br/>(No secret)"| B

    B -->|"2. Call with<br/>API Key"| C

    C -->|"3. Response"| B

    B -->|"4. Response"| A

၁၄.၇ Network Security & MitM Attacks

Network ပေါ်မှာ Data ပို့ရင် အမြဲတမ်း သတိထားရမှာက "ကြားကလူ ဖြတ်ဖတ်နိုင်တယ်" ဆိုတာပါပဲ။ ဒါကို Man-in-the-Middle (MitM) Attack လို့ ခေါ်ပါတယ်။

ဥပမာ - Coffee Shop က Free Wi-Fi ကို သုံးနေတုန်း Hacker က အဲဒီ Wi-Fi ကို ထိန်းချုပ်ထားရင်၊ ကိုယ်ပို့သမျှ Data တွေကို သူ မြင်ရပါမယ်။

sequenceDiagram

    participant User

    participant Hacker

    participant Server

    User->>Hacker: Send Login (username/password)

    Note over Hacker: Intercepts & Reads Data

    Hacker->>Server: Forwards Request

    Server-->>Hacker: Sends Success Token

    Hacker-->>User: Forwards Token

    Note over User, Hacker: User thinks connection is secure

Protection Mechanisms (ကာကွယ်နည်း)

၁. HTTPS (TLS) is Mandatory!

ဒါကို ကာကွယ်ဖို့ HTTPS (TLS) ကို မဖြစ်မနေ သုံးရပါမယ်။

HTTPS သုံးထားရင်၊ ကြားက Hacker က Data ကို ဖမ်းမိရင်တောင် Encrypted ဖြစ်နေလို့ ဘာမှ နားလည်မှာ မဟုတ်ပါဘူး။ Mobile App တွေမှာဆိုရင် SSL Pinning (Server ရဲ့ Certificate ကို App ထဲမှာ Lock လုပ်ထားတာ) သုံးရင် ပိုစိတ်ချရပါတယ်။

၂. HMAC (Data Integrity)

Data ပို့ရာမှာ "လမ်းမှာ အပြင်ခံရလား" သိဖို့ HMAC သုံးပါတယ်။

API Request ပို့တဲ့အခါ Sign(Body + SecretKey) လုပ်ပြီး Signature ထည့်ပေးလိုက်တာမျိုးပါ။

Server က လက်ခံရရှိတဲ့ Body ကို သူ့ဆီက SecretKey နဲ့ ပြန် Sign ကြည့်မယ်။ Signature တူမှ လက်ခံမယ်။ ဒါဆိုရင် Hacker က Body ကို ပြင်လိုက်ရင် Signature မတူတော့တဲ့အတွက် ပယ်ချနိုင်ပါတယ်။

၁၄.၈ Web Security: XSS & CSRF

Web Developer တိုင်း သိထားရမယ့် ရန်သူတော် ကြီး ၂ ကောင် ရှိပါတယ်။

၁. XSS (Cross-Site Scripting)

Hacker က ကိုယ့် Web Page ထဲမှာ JavaScript လာ Run တာပါ။

• Scenario: Facebook Comment မှာ <script>stealCookies()</script> လို့ ရေးပြီး Post တင်လိုက်တယ်။ တခြားလူတွေ အဲဒီ Comment ကို မြင်တာနဲ့ Script က အလိုလို Run ပြီး Cookie တွေ ပါသွားရော။

• Mitigation: User Input မှန်သမျှကို HTML အနေနဲ့ မပြဘဲ Escape လုပ်ပြီးမှ ပြရမယ်။ Modern Framework တွေ (React, Vue) က ဒါကို Auto လုပ်ပေးပါတယ်။ dangerouslySetInnerHTML လိုမျိုးကို ရှောင်ပါ။

၂. CSRF (Cross-Site Request Forgery)

User ကို အလိမ်အညာ Link နှိပ်ခိုင်းပြီး၊ User မသိဘဲ နောက်ကွယ်ကနေ Request ပို့ခိုင်းတာပါ။

• Scenario: User က Bank Website ကို Login ဝင်ထားတယ်။ ပြီးတော့ Hacker ပို့တဲ့ Email ထဲက "Win Prize" ခလုတ်ကို နှိပ်လိုက်တယ်။ အဲဒီခလုတ်က Bank Website ဆီ "Transfer $1000 to Hacker" ဆိုတဲ့ Request ကို ပို့လိုက်တယ်။ Browser က Cookie သိမ်းထားတော့ Bank က User ကိုယ်တိုင် ပို့တယ်ထင်ပြီး ငွေလွှဲပေးလိုက်တယ်။

• Mitigation:

  • Anti-CSRF Token: Form တိုင်းမှာ Random Token ထည့်ပေးထားတာ။ Hacker က ခလုတ်နှိပ်ခိုင်းလို့ ရပေမယ့်၊ ဒီ Token ကို မသိနိုင်လို့ Request က Fail ဖြစ်သွားမယ်။

  • SameSite Cookie: Cookie ကို ကိုယ့် Domain ကလွဲရင် တခြားကနေ မပါသွားအောင် SameSite=Strict သတ်မှတ်ထားတာ။

sequenceDiagram

    participant User

    participant MaliciousSite

    participant Bank

    User->>Bank: 1. Login (Session Cookie Set)

    User->>MaliciousSite: 2. Visit Attacker's Site

    MaliciousSite->>Bank: 3. Auto-submit Form (Transfer Money)

    Note right of MaliciousSite: Browser sends Bank's Cookie automatically!

    Bank->>Bank: 4. Check Cookie (Valid) -> Transfer Success (Hacked!)

    Note over Bank: Fix: Check CSRF Token. <br/>Attacker doesn't know the token!

၃. JWT (JSON Web Token) Implementation Faults

Stateless Authentication အတွက် JWT ကို သုံးကြပေမယ့်၊ အန္တရယ်များတဲ့ အချက်တွေ ရှိပါတယ်။

• Algorithm None Attack: Hacker က JWT Header ထဲမှာ {"alg": "none"} လို့ ပြောင်းပြီး Signature အပိုင်းကို ဖြုတ်လိုက်ရင်၊ Backend က မစစ်ဆေးဘဲ လက်ခံမိတတ်ပါတယ်။

• Weak Secret: HMAC Secret key ကို နာမည်ကြီး words (secret, password123) ပေးထားရင် Brute Force နဲ့ ဖောက်လို့ လွယ်ပါတယ်။

• Mitigation:

  • Library တွေမှာ algorithm: none ကို disabled လုပ်ထားပါ။

  • Secret Key ကို အရှည်ကြီး (random 32 chars+) ပေးပါ။

  • Validating Claims: exp (Expiration) နဲ့ iss (Issuer) ကို အမြဲ စစ်ပါ။

၄. CORS vs CSP (Browser Security Headers)

Web Security မှာ မပါမဖြစ် Header ကြီး ၂ ခု ရှိပါတယ်။

CORS (Cross-Origin Resource Sharing)

Browser က Domain မတူရင် (Example: frontend.com ကနေ api.backend.com ကို) API ခေါ်ခွင့် မပေးပါဘူး။

Backend က Access-Control-Allow-Origin: https://frontend.com လို့ ခွင့်ပြုပေးမှ ရပါတယ်။

• Danger: Access-Control-Allow-Origin: * (Any) လို့ ပေးလိုက်ရင်၊ Hacker ရဲ့ Site ကနေလည်း ကိုယ့် API ကို လှမ်းခေါ်ပြီး User data ခိုးလို့ ရသွားပါလိမ့်မယ်။

CSP (Content Security Policy)

XSS ကို ကာကွယ်ဖို့ အကောင်းဆုံး လက်နက်ပါ။ ကိုယ့် Page ပေါ်မှာ ဘယ် Domain က Script တွေကိုပဲ Run ခွင့်ပြုမယ်ဆိုတာ သတ်မှတ်တာပါ။

• Example: Content-Security-Policy: script-src 'self' https://trusted.cdn.com;

• ဒါဆိုရင် Hacker က <script src="hacker.com/evil.js"> လို့ ထည့်လိုက်ရင် Browser က Block လုပ်ပစ်ပါလိမ့်မယ်။

၁၄.၉ DevSecOps Pipeline

Security ကို နောက်ဆုံးမှ မစစ်ဘဲ၊ Development အဆင့်ဆင့်မှာ Checkpoint တွေ ခံထားတာပါ။

graph LR

    Dev[Developer] -->|Commit| Git

    Git --> Secrets[Secret Scan]

    Secrets --> SAST

    subgraph "Automated Security Checks"

        SAST(Code Scan) --> SCA(Dependency Scan)

        SCA --> Build[Container Build]

        Build --> ContainerScan[Image Scan]

        ContainerScan --> DAST(Attack Simulation)

    end

    DAST -->|Pass| Deploy

    Deploy --> Monitor(Runtime Security)

1. Pre-commit Hook: Developer စက်မှာ Code မတင်ခင် Secret Key ပါ၊ မပါ အရင်စစ်တယ်။ (Tool: Talisman, GitLeaks)

2. SAST (Static Application Security Testing): Code ကို မ Run ဘဲ ဖတ်ပြီး အမှားရှာတာ။ (Tool: SonarQube)

3. SCA (Software Composition Analysis): သုံးထားတဲ့ Library တွေမှာ အပေါက် (Vulnerability) ရှိလား စစ်တာ။ (Tool: Snyk, Dependabot)

4. DAST (Dynamic Application Security Testing): App ကို တကယ် Run ပြီး အပြင်ကနေ Hacker လို တိုက်ခိုက်ကြည့်ပြီး စစ်တာ။ (Tool: OWASP ZAP)

၁၄.၁၀ Summary

ဒီအခန်းမှာ ပြောခဲ့တဲ့ အရေးကြီးဆုံး အချက်တွေကို ပြန်ချုပ်ကြည့်ရအောင်။

1. Security by Design: ပြီးမှ ထည့်လို့ မရဘူး။ အစကတည်းက စဉ်းစားပါ။

2. Least Privilege: လိုသလောက်ပဲ ပေးပါ။ မပိုစေနဲ့။

3. Validate Inputs: User ဆီက ဘာလာလာ မယုံပါနဲ့။ အမြဲ စစ်ပါ။

4. Encrypt Sensitive Data: Data ကို အလွတ် မထားပါနဲ့။ Password ဆို Hash လုပ်ပါ။

5. Audit Logs: ဘာဖြစ်သွားလဲ ပြန်ကြည့်လို့ရအောင် မှတ်တမ်းတင်ထားပါ။

Security ဆိုတာ "Destination" (ပန်းတိုင်) မဟုတ်ပါဘူး၊ "Journey" (ခရီးစဉ်) ဖြစ်ပါတယ်။

Hacker တွေက နေ့တိုင်း နည်းလမ်းအသစ်တွေ ရှာနေကြသလို၊ ကျွန်တော်တို့ကလည်း နေ့တိုင်း Update လုပ်နေရမှာပါ။

Final Advice: "Paranoid ဖြစ်တာ ကောင်းပါတယ်။ ကိုယ့် Code ကို ဘယ်သူမှ မဖောက်နိုင်ပါဘူးလို့ ဘယ်တော့မှ အာမခံချက် မပေးပါနဲ့။"