Nền tảng · 35–50 phút · Foundation

, &

Đọc request/response, method, , status và hiểu bảo vệ transport chứ không tự sửa lỗi logic ứng dụng.

SAU BÀI NÀY ÔNG SẼ
  • Giải thích , & bằng ngôn ngữ của chính mình
  • Dùng để tách quan sát khỏi kết luận
  • Hoàn thành lab , & an toàn và nêu được /
LÀM CÙNG NHAU · SAFE LAB

Làm cùng nhau: đọc một request và response

Tách rõ “trình duyệt hỏi gì” với “server đã quyết định gì”.

  1. Bước 1: Đọc dòng đầu `GET /profile /1.1` trong ví dụ protocol.

    Kết quả cần thấy: Bạn biết client đang yêu cầu xem profile, không phải gửi dữ liệu để sửa profile.

    Vì sao: Method và path là để hiểu action trước khi nhìn nội dung trang.

    Đừng nhầm: Mã 200 không có nghĩa người dùng được phép làm mọi việc; nó chỉ nói request này thành công.

  2. Bước 2: So `: =demo` với body response chỉ chứa tên Alice.

    Kết quả cần thấy: đại diện phiên đăng nhập, còn response chỉ là dữ liệu server chọn trả về.

    Vì sao: Tách credential khỏi dữ liệu giúp sau này hiểu , .

    Đừng nhầm: Đừng ghi thật vào ảnh chụp hoặc note chia sẻ; đó có thể là thông tin nhạy cảm.

  3. Bước 3: Đổi trong suy nghĩ path `/profile` thành `/settings` và dự đoán điều phải thay đổi.

    Kết quả cần thấy: Server phải tự kiểm tra và quyền lại cho action mới, dù browser gửi giống nhau.

    Vì sao: là quyết định phía server cho từng object/action, không phải niềm tin mù quáng vào UI.

    Đừng nhầm: Không thử thay URL trên hệ thống không được phép; chỉ làm biến thể trong lab hoặc được cấp quyền.

01

Bức tranh lớn

Đọc request/response, method, , status và hiểu bảo vệ transport chứ không tự sửa lỗi logic ứng dụng. Chủ đề này quan trọng vì là giao thức request/response; đi qua . xác thực endpoint theo certificate và tạo kênh mã hóa, nhưng server vẫn có thể có , SQLi hoặc flaw. Khi đi , hoặc , phần khó thường không phải nhớ tên công cụ mà là nhận ra mô hình này trong một biến thể mới. Ở mạng máy tính, đừng nhìn “Internet” như một khối. Tách name resolution, addressing, route, transport, và application. Mỗi lớp có tín hiệu đo được riêng, vì vậy lỗi ở lớp nào phải được kiểm chứng bằng bằng chứng của lớp đó. Mục tiêu của phần nền tảng là dự đoán được hệ thống sẽ làm gì trước khi chạy lệnh. Nếu output khác dự đoán, dùng khác biệt đó để cập nhật mental model. Trước khi sang phần tiếp theo, hãy tự nói lại chủ đề “, & ” bằng hai câu: hệ thống đang cố làm gì, và quyết định nào có thể tạo ra rủi ro nếu sai.

02

Mental model & từ khóa

là giao thức request/response; đi qua . xác thực endpoint theo certificate và tạo kênh mã hóa, nhưng server vẫn có thể có , SQLi hoặc flaw. Các thuật ngữ trọng tâm của bài là: , , , , . Hãy liên kết chúng với luồng dữ liệu và quyết định bảo mật thay vì học định nghĩa rời rạc. Các từ khóa cần nối thành một mô hình duy nhất gồm: , , , , . Đừng học chúng như flashcard rời rạc. Hãy chỉ ra dữ liệu đi từ đâu tới đâu, thành phần nào giữ state, thành phần nào ra quyết định và đâu là . Khi mô hình đúng, bạn có thể dự đoán một thay đổi nhỏ sẽ làm output thay đổi thế nào. là giao thức request/response; đi qua .

GET /profile HTTP/1.1
Host: training.local
Cookie: session=demo

HTTP/1.1 200 OK
Content-Type: application/json

{"name":"Alice"}
03

Quy trình quan sát có kiểm chứng

request cần method, path, headers, body và context. So sánh status, , body length và semantic response khi thay một input. Luôn bắt đầu bằng expected behavior rồi mới tìm deviation; như vậy bạn biết mình đang chứng minh điều gì. request cần method, path, headers, body và context. So sánh status, , body length và semantic response khi thay một input. Bắt đầu bằng expected behavior và một sạch. Sau đó chỉ thay một biến, ghi input/output, timestamp hoặc state cần thiết rồi lặp lại để loại trừ ngẫu nhiên. Nếu tool đưa ra một nhãn như “open”, “vulnerable”, “failed” hay “suspicious”, quay về field thô tạo ra nhãn đó và xác minh bằng cách thứ hai. Đây là thói quen giúp tránh và cũng giúp report tái hiện được.

04

Case lab: từ dữ kiện tới kết luận

Phân tích ba request/response giả lập: xác định method, auth state, , và điểm nào thuộc hay . Đây là tình huống tổng hợp trong lab của khóa học, không dùng target thật. Bài thực hành trọng tâm là: Phân tích ba request/response giả lập: xác định method, auth state, , và điểm nào thuộc hay . Khi làm, chia note thành bốn cột: FACT (thấy trực tiếp), HYPOTHESIS (giả thuyết), TEST (thay đổi nào sẽ phân biệt các giả thuyết) và RESULT (kết quả). Sau khi có đáp án, tạo ít nhất hai biến thể: đổi identity/context và đổi input/state. Nếu kết luận vẫn đứng vững qua các biến thể, bạn mới có confidence cao hơn.

05

Bẫy tư duy & cách tự debug

Lỗi hay gặp là nhìn thấy một tín hiệu rồi gắn ngay nhãn vulnerability hoặc dùng công cụ trước khi hiểu hệ thống. Với chủ đề này, hãy nhớ: bảo vệ kênh truyền nhưng không tự ngăn lỗi logic ứng dụng. Với bài này, mệnh đề phải giữ là: bảo vệ kênh truyền nhưng không tự ngăn lỗi logic ứng dụng. Nếu bị kẹt, đừng tăng số lượng command/payload một cách mù quáng. Quay lại , thu hẹp câu hỏi, kiểm tra assumptions và đọc error/output theo từng lớp. Trong lab hoặc , đặt rồi đổi hướng khi không có mới; trong /, luôn kiểm tra trước khi mở rộng bề mặt thử nghiệm.

06

Phòng thủ, & tiêu chí qua bài

Dùng đúng cấu hình, , HSTS khi phù hợp và validation/ phía server. Không nhầm in transit với . Khi review fix, kiểm tra cả positive case, negative case và một biến thể gần kề để tránh vá đúng một chuỗi kiểm thử. Một tốt phải chỉ ra root cause, control đặt ở đúng và cách . Hãy kiểm tra positive case hợp lệ, negative case bị từ chối và ít nhất một biến thể gần kề để tránh “vá đúng payload”. Bạn có thể coi mình qua bài khi: (1) giải thích , & không nhìn tài liệu; (2) dự đoán được một output mới; (3) hoàn thành lab bằng ; (4) nêu được cách phòng thủ; và (5) phân biệt được observation với conclusion.

THỰC HÀNH AN TOÀN · GUIDED

Bài tập

Phân tích ba request/response giả lập: xác định method, auth state, , và điểm nào thuộc hay . Deliverable: ghi trạng thái ban đầu, dự đoán kết quả trước khi thao tác, chụp lại output quan trọng và giải thích chênh lệch giữa dự đoán với thực tế. Làm lại một biến thể nhỏ để chứng minh bạn hiểu mô hình chứ không chỉ nhớ đúng một ví dụ.

Gợi ý: Đừng tìm đáp án ngay. Với , & , ghi trước, thay đúng một biến rồi giải thích vì sao output đổi hoặc không đổi.
safe-terminal · /home/student/lab
MEMORY ONLY
WhiteHat Safe Terminal v2 · MEMORY-ONLY SIMULATOR · gõ help để bắt đầu.
$
KNOWLEDGE CHECK · CẦN 80%

5 câu kiểm tra

Không trừ điểm. Mục tiêu là giải thích được lý do, không phải đoán đúng.

Câu 1/5

Phát biểu nào đúng nhất về , & ?

Câu 2/5

Trong một lab về “, & ”, nào phù hợp nhất để bắt đầu kiểm chứng?

Câu 3/5

Control/ nào bám sát chủ đề “, & ” nhất?

Câu 4/5

Mental model nào nên giữ khi gặp một biến thể mới của “, & ”?

Câu 5/5

Nếu bài “, & ” cần thao tác có tính offensive, môi trường nào phù hợp?

PROGRESS

Đánh dấu hoàn thành

Cần đạt ít nhất 80% quiz trước khi chốt bài.