thắc mắc Ưu điểm của bảo mật ứng dụng trên mobile so với web app?

karenshii

Senior Member
Xin chào,
Mình là dev web app. (chưa dev mobile app bao giờ), mình đang có chút thắc mắc về độ bảo mật của app trên 2 nền tảng này.
Chả là giờ mình vào VCB Digital trên web, thì bắt buộc phải vào app mobile bật tính năng cho phép.
Và cái ứng dụng SMS OTP đang dần dần bị recommend chuyển sang dùng cái Smart OTP trên mobile luôn.
Thấy có vẻ như mobile đang cho bảo mật cao hơn? nhưng mình thấy đâu có liên quan gì đâu nhỉ, căn cứ vào đâu vậy? cả mobile và web đều là call tới api của bank.
Nếu intercept request/response thì cả 2 bên đều như nhau.
Virus, keylogger thì PC hay mobile cũng đều có.
Thậm chí dùng SMS OTP, mình còn có "cảm giác" an toàn hơn. Vì sms và app nó độc lập với nhau. Còn nếu dùng Smart OTP thì việc xác thực, thấy rất transparent với người dùng (chạm 1 cái hiện OTP, chạm 1 cái đồng ý với OTP đó @@). Cảm giác lỡ mất điện thoại thì nguy hiểm vô cùng.

Ai thông não giúp câu hỏi ngu ngơ của mình với.
Mình cảm ơn.
 
Chuyên sâu thì mình không rõ nhưng mà đang có task implement một hệ thống Identity Management thì thấy là bảo mật cho môi trường Web App và Single Page App có khá nhiều vấn đề phải consider so với môi trường Native App.

Vd vấn đề đơn giản nhất là lưu trữ access_token/refresh_token.

Bên Native App ít thứ phải consider hơn, thấy bên này người ta vứt vào KeyChain, KeyStore là xong.

Còn bên Web App đặc biệt là Single Page App thì phức tạp hơn nhiều. Vd như phải consider có nên generate refresh_token hay không? Rồi lưu trữ ở đâu cho hợp lý, nếu lưu ở localStore/sessionStore thì phải rất kỹ chống XSS, nếu lưu ở cookie thì phải chống CSRF. Lưu ở localStore/sessionStore thì phía backend đơn giản hơn, còn nếu lưu ở cookie thì phía backend phải xử lý phức tạp hơn cho các loại client... :confuse:
 
Về bảo mật thì native app sẽ khó bị chèn script scam hơn nhiều, native app sẽ tận dụng đc tính năng bảo mật của os như faceid, touchid. Nhưng theo mình thì vấn đề để chuyển sang chuyển về mobile app nó nằm nhiều hơn ở trải nghiệm người dùng, thu thập được nhiều thông tin người dùng hơn cũng như chi phí vận hành, 1 sms tốn khoảng 400đ nhưng bạn thử nhân lên 1 hệ thống lớn gửi cả triệu otp 1 ngày thì sẽ ra sẽ rất tốn chi phí

via theNEXTvoz for iPhone
 
Trên mobile hạn chế được lộ API hơn. Nó ngăn bắt ssl nếu sai chứng chỉ. Một số máy root thì có thể bypass, web thì không làm được.

Cơ chế sinh mã thì không dễ dàng biết như web, trên app có cơ chế bên dịch mã nguồn. Web thì chỉ tương tác với js. Một số dữ liệu local được che giấu cẩn thận hơn.

App kiểm soát phần cứng tốt hơn. Ngoài ra kiểm soát vòng đời của màn hình tốt hơn.
Ngoài ra còn một số dịch vụ chạy nền, tương tác vào hệ thống hệ điều hành để tracking thiết bị. Web fake rất dễ.

Ngoài ra web chạy chậm hơn app.
 
ngoài những điểm khá đúng bên trên, đối với bank app, nhất là software token, app có nhiều điểm bảo mật hơn web, và hơn sms. mình kể sơ sơ một số thứ sau mà web k có.

1. anti malware: ở singapore tất cả bank app đều chạy library phát hiện root, jailbreak, malware khá hiệu quả, nhưng đắt đỏ. độ hiệu quả được kiểm tra thường xuyên bởi team bảo mật
Ở vn mình đoán cũng vậy.

2. sms có thể bị đọc, gửi cho 3rd party nếu user cài app sms của hacker hoặc cấp quyền đọc sms. cái này user của mình bị rồi.
sim card có thể bị chiếm dụng, đánh cắp.
web có thể bị user cài pluggin, addons đánh cắp thông tin hoặc bản thân browser chính là malware.

3. Ngoài ra còn có ssl cert pining, touch id, keychain như các bạn nói.
cơ chế e2e encryption trên app cũng dễ che giấu hơn web.
các app trên ios độc lập với nhau và khó bị can thiệp.

Về chi phí theo kinh nghiệm của mình thì software token đắt hơn sms, vì đa số bank thuê vendor và trả tiền theo lượng token quản lý.
 
Còn bên Web App đặc biệt là Single Page App thì phức tạp hơn nhiều. Vd như phải consider có nên generate refresh_token hay không? Rồi lưu trữ ở đâu cho hợp lý, nếu lưu ở localStore/sessionStore thì phải rất kỹ chống XSS, nếu lưu ở cookie thì phải chống CSRF. Lưu ở localStore/sessionStore thì phía backend đơn giản hơn, còn nếu lưu ở cookie thì phía backend phải xử lý phức tạp hơn cho các loại client... :confuse:
Tôi thấy anh nói dài dòng mà sai sai sao ấy. Khi anh đã dùng SPA thì anh phải xài RestAPI rồi và nó stateless, cookie ở đây ko có ý nghĩa nữa (trừ khi anh cố tình xài, thế thì ko dc tính là RestAPI mà là HTTP Request).

Ngoài ra, local hay session storage bên client đơn giản là nó store string, anh tính in token ra DOM hay sao mà fải lo XSS??
 
Mình nghĩ cả webapp hay mobile app, nó đều là phía client. mà đã là client thì để bảo mật một cách hoàn hảo thật sự rất khó. chỉ có thể ngăn cản được người khác nhòm ngó thôi.
 
App ngân hàng sẽ hơn web ở chỗ khó bị lừa vào url giả hơn (thực tế vẫn có thể lừa bằng deeplink giả nhưng scam app sẽ bị phía appstore chặn rồi). Cái thứ 2 là smartotp, kĩ thuật này ko làm trên web đc.

Tôi thấy anh nói dài dòng mà sai sai sao ấy. Khi anh đã dùng SPA thì anh phải xài RestAPI rồi và nó stateless, cookie ở đây ko có ý nghĩa nữa (trừ khi anh cố tình xài, thế thì ko dc tính là RestAPI mà là HTTP Request).

Ngoài ra, local hay session storage bên client đơn giản là nó store string, anh tính in token ra DOM hay sao mà fải lo XSS??
Restful thì cũng phải có bearer token hay tương tự, và token này thường lưu trong cookie. Xss có thể dùng nội dung chuyển khoản để inject script (lý thuyết là vậy, còn thực tế tôi chưa thấy NH nào cho điền nội dung ck có kí tự đặc biệt)
 
App ngân hàng sẽ hơn web ở chỗ khó bị lừa vào url giả hơn (thực tế vẫn có thể lừa bằng deeplink giả nhưng scam app sẽ bị phía appstore chặn rồi). Cái thứ 2 là smartotp, kĩ thuật này ko làm trên web đc.


Restful thì cũng phải có bearer token hay tương tự, và token này thường lưu trong cookie. Xss có thể dùng nội dung chuyển khoản để inject script (lý thuyết là vậy, còn thực tế tôi chưa thấy NH nào cho điền nội dung ck có kí tự đặc biệt)
Bearer token thì anh fải pass vào Header/Body/GET params rồi, Cookie gì đây nữa? Theo chuẩn nhé https://datatracker.ietf.org/doc/html/rfc6750#section-2

Còn save access/refresh token best practice là ở local storage rồi. Cái anh kia nói save token ở local storage bị XSS, XSS gì ở đây
lol.gif
 
App ngân hàng sẽ hơn web ở chỗ khó bị lừa vào url giả hơn (thực tế vẫn có thể lừa bằng deeplink giả nhưng scam app sẽ bị phía appstore chặn rồi). Cái thứ 2 là smartotp, kĩ thuật này ko làm trên web đc.
Deeplink ở một số app trên browser của app hiển thị ko đầy đủ hoặc hoàn toàn ko hiển thị. nên khá khó để nhận biết. còn ở trên trình duyệt có 1 cái khá hay. đó là tự động điền mật khẩu, nó kiêm luôn việc kiểm tra mình đã từng đăng nhập site đó hay chưa.
Smart OTP mình thấy khá giống 2FA, nó có thể được thêm trên Authy hay Google Authenticator mà 2FA thì xài được trên cả app và webapp
 
Bearer token thì anh fải pass vào Header/Body/GET params rồi, Cookie gì đây nữa? Theo chuẩn nhé https://datatracker.ietf.org/doc/html/rfc6750#section-2

Còn save access/refresh token best practice là ở local storage rồi. Cái anh kia nói save token ở local storage bị XSS, XSS gì ở đây
lol.gif


có vẻ anh chưa hiểu rõ frontend hoạt động thế nào...

Bearer token phải lưu dưới browser, lưu vào localstorage hay cookie gì chẳng đc, tôi ko biết best practice của anh ở đâu nhưng lưu localstorage là ko serverside rendering đc rồi đó. Xài cookie đâu có nghĩa phải đính kèm nó trong restapi request.

xss là cách inject script để đánh cắp thông tin, bất kể website nào cũng cần chống xss chứ ko riêng app NH. Xss có thể hoạt động khi tôi gửi 10k cho anh với nội dung <script src=hacking.js>, vậy là khi anh mở web lên đã load file js của tôi, trong này tôi có thể get localstorage rồi gửi đi khắp nơi rồi đó.
 
có vẻ anh chưa hiểu rõ frontend hoạt động thế nào...

Bearer token phải lưu dưới browser, lưu vào localstorage hay cookie gì chẳng đc, tôi ko biết best practice của anh ở đâu nhưng lưu localstorage là ko serverside rendering đc rồi đó. Xài cookie đâu có nghĩa phải đính kèm nó trong restapi request.

xss là cách inject script để đánh cắp thông tin, bất kể website nào cũng cần chống xss chứ ko riêng app NH. Xss có thể hoạt động khi tôi gửi 10k cho anh với nội dung <script src=hacking.js>, vậy là khi anh mở web lên đã load file js của tôi, trong này tôi có thể get localstorage rồi gửi đi khắp nơi rồi đó.
Có vẻ anh chưa hiểu rõ tôi đang nói gì với anh kia thì đúng hơn.

Nguyên văn của anh kia:
Vd như phải consider có nên generate refresh_token hay không? Rồi lưu trữ ở đâu cho hợp lý, nếu lưu ở localStore/sessionStore thì phải rất kỹ chống XSS, nếu lưu ở cookie thì phải chống CSRF

Thế nên tôi nói với anh kia, localStorage nó chỉ lưu string. Anh lưu token vào, rồi lấy ra send request, thì liên quan gì tới XSS ở đây. Bộ anh in token ra DOM à??? Mời anh đọc kỹ lại. Còn cái vụ xss về transfer description, blah blah blah, ai chả biết
lol.gif


Còn vụ token thì thôi, anh lưu cookie thì do app anh lưu thế tôi ko ý kiến nữa. Mỗi ng` 1 kiểu
 
XSS ko phải chỉ để lấy cookie đâu các thím ơi. Ko nói về case bank này cơ mà vừa rồi có 1 bug trên app iTunes chạy trên mobile cho phép attacker chiếm quyền điều khiển điện thoại từ 1 lỗi XSS nhá :shame:
 
Có vẻ như nhiều người vẫn hiểu nhầm Cookie == Stateful và KHÔNG Stateless được!? :pudency:

Bên tôi Frontend cấm được lưu các loại token dưới localStorage/sessionStorage vì JavaScript có thể truy cập vào được. Có đội security audit luôn.

Với SPA client thì token phải lưu vào Cookie - HttpOnly - Strict vì khó bị XSS hơn và CSRF dễ chống hơn.
 
Đơn giản mà SMS không dc mã hoá , nhắn gì nhà mạng nó đoc dc hết, sms là dịch vụ của hệ điều hành dc cấp phép thì ứng dụng sẽ truy cập dc, thao tác out ra đoc tin nhắn tốn nhiều thời gian cũng tạo cơ hội nếu bị cài ứng dụng ghi lại màn hình
 
giờ làm gì có webserver nào để lọt xss đâu, thứ nữa csrf cũng phế luôn nếu refesh token với những request quan trọng, các anh toàn đưa ra phỏng đoán có thể xảy ra nào là xss , csrf tôi thấy khó nếu thằng hacker không chiếm hoàn toàn được máy ( nếu nó chiếm hoàn toàn đc máy thì chả khác gì nó là owner rồi ), nên nếu xảy ra lỗ hổng thì không phải là do ứng dụng hay là web mà là do thằng dev làm server thôi, kiểm soát không tốt thì trên app hay trên web đều chết cả .... nếu mà có cách mã hóa toàn bộ file ứng dụng về nhị phân như các file .exe hoặc đóng gói lại thành library như .dll trên window thì khả năng cao app có lợi thế hơn thật... còn bây giờ bọn nó mò lỗ hổng chỉ cần decompile file ứng dụng ra rồi mòi thì lại chả dễ
 
giờ làm gì có webserver nào để lọt xss đâu, thứ nữa csrf cũng phế luôn nếu refesh token với những request quan trọng, các anh toàn đưa ra phỏng đoán có thể xảy ra nào là xss , csrf tôi thấy khó nếu thằng hacker không chiếm hoàn toàn được máy ( nếu nó chiếm hoàn toàn đc máy thì chả khác gì nó là owner rồi ), nên nếu xảy ra lỗ hổng thì không phải là do ứng dụng hay là web mà là do thằng dev làm server thôi, kiểm soát không tốt thì trên app hay trên web đều chết cả .... nếu mà có cách mã hóa toàn bộ file ứng dụng về nhị phân như các file .exe hoặc đóng gói lại thành library như .dll trên window thì khả năng cao app có lợi thế hơn thật... còn bây giờ bọn nó mò lỗ hổng chỉ cần decompile file ứng dụng ra rồi mòi thì lại chả dễ
Mình không thích kiểu mindset giống bạn, bạn là kỹ sư, bạn thiết kế, bạn phải tuân theo những quy tắc. Layer nào làm tốt nhiệm vụ của layer đó. Không thể mindset kiểu là, có ai kết nối được vào db đâu, cần gì phải hash password của user. Code mình đã có authen user rồi, vậy chả cần gì phải restrict theo IP nữa, cần gì phải VPN mệt nhoài, cứ expose ra thôi.
 
Về mặt kỹ thuật thì có vẻ như nhau. Nhưng hãy xét cơ bản dưới góc độ người dùng. Thường lừa đảo sẽ gửi tin nhắn mạo danh web NH (giao diện giống hệt, chỉ khác đg dẫn) để lấy ID và mật khẩu. Sau đó hacker đăng nhập và yc khách hàng gửi OTP. Khoá bản web vào thì hacker đăng nhập trên app sẽ yc chuyển đổi thiết bị ... Người dùng bình thường sẽ khó bị hack hơn
 
Back
Top