Em có nghe người ta nói ajax là công nghệ web 2.0, nó giúp cho ứng dụng web trở nên thân thiện hơn cho người dùng, tuy nhiên song song với nó là tạo nên các lỗ hổng bảo mật thậm chí nghiêm trọng, mà các lập trình viên phải toát mồ hôi và sôi nước mắt. Sự thể trên là thế nào?, mong các anh chị em giải chổ nghi giúp mình với!!!, trân trọng…
Xin được chỉ giáo về bảo mật của web sử dụng ajax
Đối với web thì ajax hay không ajax nó vẫn bảo mật như nhau, tất cả xử lí logic transaction phải để cho server gánh, còn lại thì cứ thoải mái cho phía client muốn làm gì thì làm - không bao giờ tin tưởng người dùng cả.
Web 2.0 là sao? HTTP 2.0 hay là cái gì vậy?
Nếu là HTTP 2.0 thì ajax nó có từ 1.0 rồi mà
2 Likes
Web 2.0 tức web động và webapp
1 Like
Vậy web 2.0 bao gồm không sử dụng ajax và sử dụng ajax???
Ajax chỉ là công nghệ, web dynamic kết nối db, xử lý request người dùng từ server rồi trả về client cũng là web 2.0
Ajax giúp bạn có trải nghiệm web tốt hơn bằng cách truyền tải data mà không cần load lại trang. VD như thanh search có gợi ý bên dưới mỗi khi bạn đang gõ. Hay thanh loading khi chờ data load về. Hay kết nối với Web Service nhận kết quả là JSON hay XML rồi dùng Js trỏ DOM đổ vào giao diện client
Về Ajax không có gì đáng ngại về bảo mật, vì nó chỉ là trung gian xử lý mà thôi, thứ bạn quan tâm về bảo mật là Web Service, nếu bạn tách phần xử lý request ra khỏi webapp, dùng Ajax để gửi request và respone cho Web Service xử lý
1 Like
Hình như người dùng có thể dùng cái postman extension để sửa tham số trong post data phải không bạn?
Câu hỏi của bạn có rất nhiều keyword nhưng có vẻ bạn chưa làm bài tập về những công nghệ đó và không hiểu mình đang định hỏi về cái gì?
Mình nghĩ hướng tìm hiểu mà bạn có thể tham khảo là:
- Tìm hiểu về AJAX.
- Thuật ngữ “Web 2.0” là gì?
- Về bảo mật, bạn đang nói về những dạng bảo mật gì?
Mình tin chắc là sau khi tìm hiểu và làm bài tập đầy đủ, câu hỏi ở trên của bạn sẽ rõ ràng hơn.
1 Like
Có sửa query, body data đằng trời bằng postman hay cái gì khác đi nữa mà server verify cái đó thì chả có gì gọi là lỗ hổng đc.
Giờ 99% là có dùng ajax cứ yên tâm mà dùng . Quan trọng là cái gì cũng phải verify ở server vậy thôi
1 Like
Việc verify này là khá phức tạp, và nhiều vấn đề
vậy để hỏi từ từ nhé.
1_ Gửi token từ server đến client
router.get('/create_token_and_send', function (req, res) {
var Jwt = require('jsonwebtoken');
var token = Jwt.sign(tokenData, privateKey, {
expiresIn: 1440//expires in 24 hours
})
var data = { token: token }
res.render('jwt/create_token_and_send', data);
});
1.1_ Gửi token nhiều lần
1.2_ Gửi token một lần.
2_ Làm sao gửi thông tin token qua ajax
Mình lưu token ở client như thế này
localStorage.setItem('token','<%=token%>')
Làm sao gửi thông tin này qua ajax?
3_ Server nhận token này như thế nào?
4_ Xác nhận user
5_ Xác nhận user có quyền gì?
5.1_ xác nhận cấp router,
5.2_ Xác nhận cấp router và id
6_ Xử lý khi user log out. (clear token from client?)
7_ Quản lý user thế nào
user(id,name,pass,level)
list_router()…
uh, có lẽ phải chia ra nhiều topic!
hay là để tui ngrok 1 cái server anh em test thử nhé?
a. Đặt tên là ghi chu online
b. Đăng nhập bằng google acount
c. Bài toán đơn giản: Mỗi user chỉ có một quyền trên một dòng dữ liệu
ví dụ: ghi_chu(id,ten,noi_dung, user_id)
d.Chỉ sử dụng node js và angular hoặc jquery
“gửi” token từ server -> client thông thường thì mình set Cookie cho em token này, như vậy thì khi bạn post bất cứ thứ gì lên server thì sẽ tự động gửi luôn token. Và cũng nên set httpOnly để tránh bị cướp token bằng javascript.
Nếu token có exp thì lúc nào sắp hết hạn thì bạn phải refesh lại khi nó sắp hết hạn, implement thế nào thì cũng tùy vào ý định của bạn.
m hay cho hết thông tin (trừ mật khẩu) vào payload của token,
muốn xác nhận user bị ban hay ko có thể dùng middleware, implement thế nào thì cũng tùy bạn @@
res.clearCookie("token");
https://developers.google.com/identity/protocols/OAuth2WebServer[quote=“Thuc_Nguyen_tan, post:9, topic:55877”]
c. Bài toán đơn giản: Mỗi user chỉ có một quyền trên một dòng dữ liệu
[/quote]
Lười code @@ , cơ mà trả lời mấy cái trên thì chắc bạn đã mười tượng ra rồi.
1 Like
Cám ơn bạn nhé 
hai câu hỏi nữa lại phát sinh:
1_ Và cũng nên set httpOnly để tránh bị cướp token bằng javascript.
Đây là cái gì? có thể minh họa bằng đoạn code
Mình hay code thế này :
$scope.test=function(){
var promise=$http({
url:url+"/test2",
method:"POST",
headers: {'Content-Type': 'application/json'},
//data:r,
});
return promise;
};
Đặt token ở đâu?
data:{token:token} ===> server get : req.body.token
is it ok?
2_ Đăng nhập bằng google…
hix, kiến thức mình thủng nhiều quá
auth Mindleware thì còn biết
2 cái còn lại thì mới kít : CORS và CSRF
Quả là phức tạp, liệu có phải kiếm và nghiên cứu một cái framework để xài không bạn nhỉ?
- Như mình đã nói bạn đã set cookie thì mọi request bạn gửi đi đều sẽ được đính kèm token trong cookie rồi bạn ko cần phải chèn vào bất cứ chỗ nào trong code ở client. Bình thường hacker có thể lấy cookie bằng js bằng hàm sau nếu web của bạn bị Cross-Site-Scripting (dùng angular thì được protect rồi dùng jquery thì phải filter --> cực)
document.cookie
bạn set như này thì thằng js ko thể đọc được
res.cookie('token', '134324rfafdsaferfeqrw', { httpOnly: true });
2.;; Đọc doc rồi làm thôi bạn .
Google thần chưởng đế biết thêm chi tiết
1 Like
Cám ơn nhé, hình như nó tự động send theo, thk a tons
ai nói lập trình web là dễ, mình thấy nó khó hơn window app nhiều lần…!!!
Chả có thứ gì dễ đâu bạn, càng xuống tầng dưới nó càng rắc rối.
Code web thì bảo mật tầng dữ liệu server toàn quyền, khá đơn giản, còn về code app, ví dụ game online, để quản lí cái dữ liệu qua lại giữa client-server là một vấn đề rất khó, gần như không có thiết kế hoàn hảo cho đến tận ngày nay, hầu hết toàn dùng trick. Source code client bị lộ ra thì cũng coi như game xác định bị hack.
1 Like
Yên tâm là học cái gì càng sâu càng khó, làm cái gì càng phức tạp càng đau não 
.
@Dao_An Mình thấy nhiều người gắn token vào header của request. Ví dụ như:
curl -H 'X-Auth-Token: ABCDEF1234567890' example.com/api/users/me
Có lý do gì khiến bạn prefer dùng cookies hơn nhỉ?
1 Like
Chèn vào header nếu bạn muốn dùng api đó cho cả app di động thì ko phải code lại phần xử lý trên server.
Mình thích cookies hơn vì sẽ an toàn hơn, ko thằng hacker nào lấy đc token của người dùng.
p/s: và còn 1 điều nữa là bạn muốn ghi nhớ đăng nhập cho người dùng trên web thì bắt buộc phải lưu trên cookie hoặc localStorage . Đằng nào chả phải dùng cookie , nếu dùng localStorage lại tốn thêm bước add token vào header @@
daynhauhoc, kipalog đều dùng cookies để lưu thông tin đăng nhập
Bạn có thể giải thích kĩ hơn chỗ này được không?
Mình thích cookies hơn vì sẽ an toàn hơn, ko thằng hacker nào lấy đc token của người dùng.
Cơ chế lưu cookies trên browser an toàn thế nào, bảo mật ra sao? Vì sao hacker không thể nào lấy được token của người dùng khi dùng cookies?
Disclaimer: Mình không phải là một web dev, mình có thể không hiểu chính xác những gì mình nói dưới đây.
Nhưng theo mình biết thì với LocalStorage ta không thể truy cập vào một localStorage của một domain khác với XHR, còn với cookies thì XHR/Fetch API cho phép “forward cookies” với XHR.withCredentials (thuật ngữ có thể không chính xác) cho một request từ một domain khác.
Nói cách khác, khi dùng cookies bạn phải deal với CSRF.
Và như bạn nói, hạn chế của cookies là nó chỉ giới hạn cho web. Là một back-end dev thì mình sẽ không thoải mái lắm với việc bị coupled vào một platform.
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
Bạn đọc bài này nói về cookies vs localStorage, họ vẫn recomend cookies hơn .
Chính xác
Gmail và Facebook vẫn dùng cookies thôi bạn, nếu muốn api cho mobile thì code riêng ra vậy @@
1 Like
bài blog giải thích khá ok lợi lại của việc dùng cookies và local storage.
1 Like
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?