API, Autentikasi, dan Keamanan · 6/7

Celah keamanan yang benar-benar akan kamu temui

XSS, SQL injection, CSRF, dan IDOR — bentuknya dalam kode, dan cara memperbaiki masing-masing.

Baca 35 menit

Setelah pelajaran ini kamu bisa

Mengenali XSS, SQL injection, CSRF, dan IDOR dalam kode
Menyebutkan perbaikan yang tepat untuk masing-masingnya
Menjelaskan bedanya escaping dan sanitising
Menjelaskan gunanya audit dependency

Empat celah keamanan mencakup sebagian besar dari yang akan benar-benar kamu temui. Kamu sudah melihat masing-masingnya secara terpisah di jalur ini; ini semuanya sekaligus, beserta perbaikannya.

Celah	Penyerangnya	Perbaikannya
XSS	Menyuntikkan script ke sebuah halaman	Escape output-nya; jangan pernah `innerHTML` untuk data pengguna
SQL injection	Menyuntikkan SQL ke sebuah query	Query berparameter, selalu
CSRF	Membuat browser korban mengirim sebuah request	Cookie `sameSite`; sebuah token untuk form
IDOR	Mengubah sebuah id untuk mengakses data orang lain	Periksa kepemilikan terhadap session-nya

XSS

Coba sendiri

Escaping, diimplementasikan. Perhatikan karakter mana yang penting dan kenapa membuang tag saja tidak cukup.

// The five characters that can change the meaning of HTML.
function escapeHtml(text) {
  return String(text)
    .replace(/&/g, "&amp;")      // must be first, or it double-escapes
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&#39;");
}

const payloads = [
  '<script>steal()</script>',
  '<img src=x onerror="steal()">',            // no script tag at all
  '<svg onload="steal()">',
  '" onmouseover="steal()" x="',              // breaks out of an attribute
  "Ana & Budi's <villa>",                     // legitimate text
];

for (const p of payloads) {
  console.log("raw:     " + p);
  console.log("escaped: " + escapeHtml(p));
  console.log("");
}

console.log('Notice payload 2 and 3 have no <script> tag. A "remove script tags"');
console.log("filter passes them straight through, and onerror still runs.");
console.log("Escaping is not filtering: it changes the characters so the browser");
console.log("renders them as text instead of parsing them as markup.");

Hasil

Tekan Jalankan untuk melihat hasilnya.

Ini jalan di browser kamu, di dalam sandbox. Apa pun yang kamu tulis di sini tidak bisa merusak situs.

SQL injection

Coba sendiri

Apa yang sebenarnya diterima database, dengan kedua cara. Bedanya adalah apakah nilainya bisa jadi sintaks.

// Building the query by joining strings.
function buildConcatenated(name) {
  return "SELECT * FROM users WHERE name = '" + name + "'";
}

// Parameterised: the query and the values travel separately.
function buildParameterised(name) {
  return { sql: "SELECT * FROM users WHERE name = ?", params: [name] };
}

const inputs = [
  "Ana",
  "' OR '1'='1",
  "'; DROP TABLE users;--",
  "' UNION SELECT password_hash, 1, 1, 1, 1, 1 FROM users--",
];

for (const input of inputs) {
  console.log("input: " + JSON.stringify(input));
  console.log("   concatenated -> " + buildConcatenated(input));
  const p = buildParameterised(input);
  console.log("   parameterised-> " + p.sql + "   params: " + JSON.stringify(p.params));
  console.log("");
}

console.log("In the concatenated version the input BECAME part of the query:");
console.log("  - the second returns every user");
console.log("  - the third destroys the table");
console.log("  - the fourth reads the password hashes");
console.log("");
console.log("In the parameterised version the query never changes shape.");
console.log("The value stays a value, whatever characters it contains.");

Hasil

Tekan Jalankan untuk melihat hasilnya.

Ini jalan di browser kamu, di dalam sandbox. Apa pun yang kamu tulis di sini tidak bisa merusak situs.

CSRF

CSRF — cross-site request forgery — tidak mencuri cookie-mu. Ia membuat *browser-mu sendiri* mengirim request yang tidak kamu maksudkan, dan cookie-mu ikut terkirim otomatis karena itulah sifat cookie.

html

<!-- On evil.example, which you visit while signed in to your bank. -->
<form action="https://bank.example/transfer" method="POST">
  <input type="hidden" name="to" value="attacker" />
  <input type="hidden" name="amount" value="1000000" />
</form>
<script>document.forms[0].submit()</script>

<!-- Your browser sends the POST, with your session cookie attached.
     The bank sees a perfectly authenticated request. -->

Coba sendiri

Dua pertahanannya, sebagai logika keputusan. SameSite saja sudah menghentikan serangan klasiknya.

// Does the browser attach the cookie to this request?
function cookieSent(sameSite, isCrossSite, method) {
  if (!isCrossSite) return true;                       // same site: always
  if (sameSite === "strict") return false;
  if (sameSite === "lax") return method === "GET";      // top-level GET only
  return true;                                          // "none": always
}

// Does the server accept it?
function accepted(sameSite, isCrossSite, method, sentToken, expectedToken) {
  if (!cookieSent(sameSite, isCrossSite, method)) return "rejected: no cookie sent";
  if (method !== "GET" && sentToken !== expectedToken) return "rejected: bad CSRF token";
  return "ACCEPTED";
}

const scenarios = [
  ["your own form",          false, "POST", "tok", "tok", "lax"],
  ["evil.example auto-POST", true,  "POST", null,  "tok", "lax"],
  ["evil.example auto-POST", true,  "POST", null,  "tok", "none"],
  ["evil.example, no token check", true, "POST", null, null, "none"],
  ["a link from another site", true, "GET",  null,  "tok", "lax"],
];

for (const [label, cross, method, sent, expected, sameSite] of scenarios) {
  const result = accepted(sameSite, cross, method, sent, expected);
  console.log((sameSite + "/" + method).padEnd(10) + label.padEnd(30) + result);
}

console.log("");
console.log("sameSite=lax blocks the cross-site POST on its own - the cookie is");
console.log("never even sent. sameSite=none removes that protection, and then only");
console.log("the token stands between you and the attack.");

Hasil

Tekan Jalankan untuk melihat hasilnya.

Ini jalan di browser kamu, di dalam sandbox. Apa pun yang kamu tulis di sini tidak bisa merusak situs.

Dependency-mu

Kamu meng-install ratusan package yang belum kamu baca. Masing-masingnya jalan dengan izinmu saat development dan di dalam server-mu di production. Ini permukaan serangan yang nyata, dan sudah pernah dipakai.

Audit secara rutin. bun audit atau npm audit mendaftar celah keamanan yang sudah diketahui di apa yang kamu install.
Commit lockfile-nya. Itu satu-satunya catatan tentang kode tepat yang kamu kirim.
Baca nama package-nya dengan teliti. Nama tiruan hasil salah ketik duduk berdampingan dengan yang asli di hasil pencarian.
Blokir script install. Mereka dieksekusi saat install, sebelum kamu menjalankan apa pun. trustedDependencies di proyek ini adalah allowlist untuk itu.
Utamakan dependency yang lebih sedikit. Setiap yang kamu hindari adalah kode yang tidak perlu kamu percayai — itu sebabnya proyek ini menulis sendiri negosiasi bahasa dan validasinya alih-alih meng-install-nya.

Tugas praktik

Jalankan bun audit di proyek ini dan baca output-nya. Lalu pilih dependency mana pun di package.json, buka foldernya di node_modules, dan baca package.json-nya — perhatikan berapa banyak dependency yang ia punya. Terakhir, jalankan ls node_modules | wc -l dan renungkan seberapa banyak kode yang kamu percayai untuk menampilkan satu situs belajar.

Hasil yang diharapkan

Beberapa ratus package, sebagian besar transitif.