Web basic

Câu 1: Sự khác biệt chính giữa các yêu cầu GET và POST là gì?
GET và POST là hai phương thức yêu cầu HTTP được sử dụng phổ biến nhất.
Mặc dù chúng được gọi là các phương thức HTTP, nhưng cả GET và POST
cũng được sử dụng trong HTTPS. Thông thường, các yêu cầu GET được sử
dụng để yêu cầu các trang web trong khi POST được sử dụng để gửi dữ liệu
đến máy chủ web, chẳng hạn như thông qua biểu mẫu web.
Sự khác biệt chính giữa GET và POST là cách thức truyền thông tin và các tác vụ
được thực hiện.

Get Post

Data is visible on the GET request
URL.
Dữ liệu hiển thị trên URL yêu cầu
GET.
Data is Not visible in the request so you can
pass sensitive data like passwords etc.
Dữ liệu không hiển thị trong yêu cầu để
bạn có thể chuyển dữ liệu nhạy cảm như
mật khẩu, v.v.

Data length should be maintained to No limit on data length is there in POST

avoid exceeding the URL length request.
limit.
Độ dài dữ liệu phải được duy trì Không có giới hạn về độ dài dữ liệu trong yêu
để tránh vượt quá giới hạn độ dài cầu POST.
URL.

It supports only string data types It supports different data types like strings,
Nó chỉ hỗ trợ các kiểu dữ liệu boolean, integers, etc
chuỗi Nó hỗ trợ các loại dữ liệu khác nhau như
chuỗi, boolean, số nguyên, v.v.

Get requests can be bookmarked Post request can’t be bookmarked

Nhận yêu cầu có thể được đánh Không thể đánh dấu yêu cầu bài viết
dấu
 Get is simple to use because of its
nature of appending data to URL
only.
Get rất đơn giản để sử dụng vì
bản chất của nó là chỉ thêm dữ
liệu vào URL.
The post requires header information, body,
etc which makes it hard to use as
compared with Get request.
Bài đăng yêu cầu thông tin tiêu đề, nội
dung, v.v. nên khó sử dụng so với Nhận
yêu cầu.

Get requests requests can be POST requests request can’t be cached.

cached. Yêu cầu POST yêu cầu không thể được
Nhận yêu cầu yêu cầu có thể lưu trữ.
được lưu trữ.

nguồn: https://www.scaler.com/topics/difference-between-get-and-post/
https://www.technipages.com/post-get-requests

Câu 2: Mục đích chính của cookie HTTP là gì?

Theo MDN, HTTP Cookie được định nghĩa như sau:
HTTP Cookie (web cookie, browser cookie) là dữ liệu được gửi từ server tới trình duyệt
của người dùng. Trình duyệt sẽ lưu dữ liệu cookie này và gửi lại theo mỗi HTTP
request về cho cùng server đó. Về cơ bản, cookie dùng để nói cho server biết
các request đến từ một trình duyệt
Đúng vậy, HTTP là giao thức stateless. Nó sẽ k chứa tt gì cho biết người dùng đó là ai.
Ví dụ: 10 cái http request từ máy A gửi đến máy B thì máy B sẽ k phân biệt đc nó
đến từ đâu và từ người dùng nào
Do đó, mọi request đến server đều giống nhau. Vì vậy, server không thể phân biệt
được request được gửi đến là từ một client đã thực hiện request trước đó, đã
đăng nhập,... hay từ một client mới.
Vì vậy, HTTP Cookie đã ra đời để giải quyết vấn đề này.
Các tác dụng của cookie
Cụ thể, các tác dụng chính của cookie là:
 Quản lý session: trạng thái đăng nhập, thông tin giỏ hàng,...
 Lưu thông tin cài đặt của người dùng: theme (dark mode hay light mode), ngôn
ngữ (tiếng việt, tiếng anh), thông tin username/email trong mục bình luận, cho 1
số trang web để có thể truy cập ra vào mà không phải login lại
 Theo dõi và phân tích hành vi người dùng: các trang đã truy cập, truy cập bao
nhiêu lần,... vì mỗi một cookie của chỉ có một id duy nhất, giả sử nếu như
một ngừ dùng A truy cập web B 2-3 lần 1 ngày, cookie sẽ cho phép đếm số
lượt truy cập này thành 1 lượt duy nhất. Như vậy người chủ web B sẽ có
thể thu thập dữ liệu một cách chính xác hơn về lượt truy cập của người
dùng
nguồn: https://completejavascript.com/tim-hieu-ve-http-cookie-voi-javascript/

Câu hỏi lab

13 Tại sao việc máy chủ phải nhận biết được một yêu cầu web có phải là cross-
site hay không là một vấn đề quan trọng?

Các máy chủ phải biết yêu cầu HTTP có phải là trang web chéo hay không vì yêu cầu
trang web chéo có thể gây rủi ro bảo mật. Yêu cầu trang web chéo xảy ra khi một trang
web gửi yêu cầu đến một miền khác với miền đã phục vụ trang web đó. Những yêu cầu
này có thể được bắt đầu bởi kẻ tấn công muốn thực hiện các hành động độc hại thay
mặt cho người dùng, chẳng hạn như đánh cắp thông tin đăng nhập của người dùng
hoặc thực hiện các giao dịch trái phép.

Mục đích các máy chủ phải biết yêu cầu HTTP có phải là trang web chéo hay không:
 Ngăn chặn các cuộc tấn công CSRF: máy chủ sẽ kiểm tra nguồn gốc của các
yêu cầu được gửi đến và xác thực rằng yêu cầu được thực hiện bởi một người
dùng hợp pháp trên cùng một trang web.

 Bảo vệ quyền riêng tư và dữ liệu: Các yêu cầu trên nhiều trang có thể được sử
dụng để trích xuất dữ liệu nhạy cảm từ người dùng, chẳng hạn như cookie hoặc
thông tin cá nhân, có thể được sử dụng để theo dõi hoặc đánh cắp danh tính.
Bằng cách thực thi các chính sách SOP, máy chủ có thể ngăn truy cập trái phép
vào dữ liệu người dùng và bảo vệ quyền riêng tư của người dùng.

 Chia sẻ tài nguyên trên nhiều nguồn gốc (CORS): Máy chủ có thể sử dụng thông
tin về nguồn gốc của các yêu cầu đến để thực thi các chính sách chia sẻ tài
nguyên trên nhiều nguồn gốc, cho phép hoặc hạn chế quyền truy cập vào các tài
nguyên trên các nguồn gốc khác nhau. Bằng cách kiểm soát quyền truy cập vào
tài nguyên trên các miền khác nhau, máy chủ có thể ngăn chặn truy cập trái
phép hoặc rò rỉ dữ liệu.
Ví dụ: nếu máy chủ không xác thực đúng nguồn gốc của yêu cầu, kẻ tấn công có thể thực hiện
cuộc tấn công CSRF, trong đó người dùng vô tình gửi yêu cầu đến máy chủ có vẻ hợp pháp
nhưng thực ra là do kẻ tấn công tạo ra . Điều này có thể cho phép kẻ tấn công thực hiện các hành
động trái phép thay mặt cho người dùng, chẳng hạn như chuyển tiền, thay đổi mật khẩu hoặc xóa
dữ liệu.

14 Có thể nào yêu cầu trình duyệt không gửi bất kỳ cookie nào cho các yêu cầu
cross-site không?

Trước hết, nếu không có cookie đi kèm với các yêu cầu cross-site, các trang web bị
hạn chế trong việc xác thực người dùng và lưu trữ thông tin liên quan đến người dùng,
như thông tin đăng nhập hoặc lịch sử duyệt web. Điều này có thể gây ra các vấn đề
về trải nghiệm người dùng và không phù hợp trong một số trường hợp sử dụng.

Tuy vậy, trình duyệt vẫn có thể được cấu hình để không gửi bất kỳ cookie nào trong
các yêu cầu chéo trang (cross-site request). Điều này được thực hiện thông qua cài đặt
SameSite Cookies
Nếu cookie có thuộc tính SameSite được đặt thành "Strict" hoặc "Lax", trình duyệt sẽ
không gửi cookie đó trong yêu cầu chéo trang. Và nếu không có cookie nào được
gửi, thì yêu cầu đó sẽ không chứa bất kỳ thông tin xác thực hoặc phiên làm việc
của người dùng, và do đó không thể bị lợi dụng để thực hiện các tấn công bảo
mật như CSRF.
Ngược lại, nếu các cookie được đặt SameSite bằng giá trị "None", thì trình duyệt sẽ
vẫn gửi cookie đó trong các yêu cầu chéo trang

15 Giả sử một trang từ www.example.com chứa một iframe, bên trong đó hiển thị
một trang Facebook nào đó. Nếu một yêu cầu được gửi từ bên trong iframe, thì
yêu cầu đó có được coi là yêu cầu chéo trang (cross-site) hay không? Nếu
không, thì làm thế nào để bảo mật điều này?
Nếu một yêu cầu được gửi từ bên trong một iframe, liệu đó có được coi là yêu cầu
chéo trang hay không phụ thuộc vào các điều kiện sau:
- Nếu iframe và trang web chứa iframe được tải từ các nguồn khác nhau,
thì yêu cầu được xem là cross-site.
- Nếu iframe và trang web chứa iframe đều được tải từ cùng một nguồn
gốc (cùng một tên miền), thì yêu cầu không được xem là cross-site.
Ở yêu cầu trên, do nguồn gốc của iframe khác với nguồn gốc của trang Facebook nên
đây được coi là yêu cầu chéo trang

Để đảm bảo an toàn cho việc này, lập trình viên có thể sử dụng biện pháp bảo mật
SameSite cookie
SameSite Cookie giải quyết vấn đề này bằng cách đặt ràng buộc trên cách cookie
được sử dụng. Nó có thể được đặt thành ba giá trị khác nhau
Bằng cách đặt thuộc tính SameSite thành Strict hoặc Lax, bạn có thể ngăn không cho
cookie được gửi cùng với các yêu cầu trên nhiều trang. Điều này có thể giúp ngăn chặn
các cuộc tấn công CSRF và bảo vệ quyền riêng tư của người dùng.
Các phương pháp xác thực khác (OAuth, JSON Web Tokens) cũng có thể được sử
dụng để xác thực và xử lý dữ liệu của người dùng trong các trang web chéo trang
một cách an toàn hơn. Tuy nhiên, việc sử dụng các phương pháp bảo mật này có
thể phức tạp và đòi hỏi kiến thức kỹ thuật cao.
Mô tả từng task 1
Vào terminal gõ lệnh sudo gedit /etc/hosts &>/dev/null &

sau đó sẽ hiển thị bảng hosts

đây là 3 trang web, truy cập vào website: www.seed-server.com

Trước khi làm mới trang web, bạn có thể mở dòng tiêu đề HTTP Header Live này sau đó có thể

nắm bắt các yêu cầu ban đầu tới máy chủ này
Ví dụ nếu bạn muốn nắm bắt tên người dùng và mật khẩu của Alice, để bắt mật khẩu

của Alice mở HTTP Header Live thì tất cả các yêu cầu HTTP được kích hoạt sẽ được

ghi lại và khi thao tác bấm vào đăng nhập với tư cách là Alice và dò tìm mật khẩu bị

bắt.

Nhấp vào kiểm tra tiện ích mở rộng tiêu đề trước khi đăng nhập vào tài khoản để mở

Thêm thông tin đăng nhập

Người dùng:

Alice

Mật khẩu

Aliceseed
Nhấp vào phần đầu tiên, bạn sẽ nhận được POST request và phần thứ hai để GET

request.
bên cạnh tên người dùng và mật khẩu nắm bắt được còn có thể thấy bất kì các thông

tin khác ví dụ như cookie.

Sơ đồ khối task 1: