Hướng dẫn này trình bày quy trình đơn giản trong việc kết hợp xác thực vào ứng dụng Next.js của bạn bằng thư viện next-auth. Mặc dù thư viện cung cấp nhiều tùy chọn (nhà cung cấp), hướng dẫn này tập trung vào việc triển khai bằng cách sử dụng Nhà cung cấp Google.

Về hướng dẫn này, mọi người cũng sẽ hiểu rõ hơn về việc dễ dàng thiết lập các tuyến được bảo vệ trong ứng dụng của mình, một nhiệm vụ được thư viện next-auth này thực hiện dễ dàng.

Thiết lập thư viện next-auth

Đầu tiên mọi người phải có 1 chiếc project nextjs đã, mọi người có thể tham khảo hướng dẫn trên trang chủ của Nextjs tại đây, hướng dẫn quá chi tiết: https://nextjs.org/docs/getting-started/installation

Cài đặt thư viện next-auth bằng lệnh sau:

npm install next-auth

Sau khi hoàn tất cài đặt, hãy tạo thư mục api trong thư mục ứng dụng gốc và bên trong thư mục đó tạo thư mục /auth. Cuối cùng, tạo thư mục […nextauth] bên trong thư mục auth đó.

Inside the [...nextauth] folder, create two files named route.ts and options.ts.

Cấu trúc thư mục của mọi người cho đến thời điểm này sẽ trông như thế này:

Sau đó, trong tệp options.ts, chèn đoạn mã sau:

import type { NextAuthOptions } from 'next-auth'
import GoogleProvider from "next-auth/providers/google";

export const options: NextAuthOptions = {
    providers: [
  GoogleProvider({
    clientId: process.env.GOOGLE_CLIENT_ID as string,
    clientSecret: process.env.GOOGLE_CLIENT_SECRET as string,
  })
]
}

việc bạn có thể thêm nhiều Provider khác sử dụng mạng xã hội các bạn có thể tham khảo tại đây, có hướng dẫn cụ thể như đoạn code GoogleProvider trên

Biến options là nơi chúng ta nhúng bất kỳ nhà cung cấp nào chúng tôi dự định sử dụng từ next-auth

Để sử dụng đăng nhập bằng Google một cách hiệu quả, mọi người cần có các thuộc tính clientId và clientSecret của mình. Hãy yên tâm, mình sẽ sớm đi sâu vào vấn đề này. Đầu tiên, tạo tệp .env nơi bạn sẽ gán giá trị cho cả hai thuộc tính đã khai báo bên trên.

lưu ý rằng tạo file .env nên đặt nó ở thư mục gốc để tránh các lỗi có thể sảy ra nếu như không config nó ở trong file config

OK giờ chúng ta cùng đi đến bước setup Google nào!!!

Setup google

Truy cập trang https://cloud.google.com/ và tiến hành tạo mới một project trên đó

Mình sẽ bỏ qua bước tạo project vì hầu như trên mạng cũng đã có rồi, mà mình sẽ hướng dẫn từ bước mọi người đã tạo xong nhé

Sau khi tạo xong các bạn sẽ được tới 1 trang như thế này, bấm theo các bước mình đã chụp ở trên, đầu tiên chọn Credentials

Sau đó ở màn hình Credentials nhấn chọn button “CONFIGURE CONSENT SCREEN”

Sau khi đã thiết lập cũng như đồng ý các điều khoản thì mọi người sẽ được chuyển tới màn hình như sau:

ở màn hình này chúng ta sẽ chả làm gì cả vì cũng chưa setup gì cho project của mình, chuyển tiếp về lại trang Credentials:

nhập các thông tin đầy đủ vào phần Create OAuth client ID:

Cuộn xuống phần “Authorize redirect URI” và dán URI sau:
http://localhost:3000/api/auth/callback/google. Sau đó bấm nút Create

Trong trường hợp mọi người muốn setup cho production thì thay vì để localhost hãy thay bằng domain của mình

Cuối cùng thì id của chúng ta cần đã xuất hiện, việc chúng ta cần làm là đưa 2 id này vào trong phần .env của dự án mình và tiến hành tới bước tiếp theo, test

Mọi người cũng cần tạo key NEXT_AUTH_SECRET để tăng cường tính bảo mật của quy trình xác thực trong next-auth. Mình từng mắc tới việc nếu không thêm key này thì không thể sử dụng tới Google được nên mọi người cứ thêm vào cho chắc nhé. Tạo secret key của mọi người bằng cách thực hiện lệnh sau:

openssl rand -base64 32

Lệnh này sẽ tạo ra một chuỗi 32 ký tự. Sao chép chuỗi này và dán nó làm giá trị cho biến NEXTAUTH_SECRET trong tệp .env này. Tệp .env cuối cùng của chúng ta sẽ giống như sau:

GOOGLE_CLIENT_ID = client ID value
GOOGLE_CLIENT_SECRET = client secret value
NEXT_AUTH_SECRET = next auth secret

Sau khi bạn đã triển khai thành công các biến .env, hãy dán đoạn mã sau vào tệp Route.ts của mình:

import NextAuth from "next-auth/next";
import { options } from "./options";

const handler = NextAuth(options);

export { handler as GET, handler as POST };

Điều này đảm bảo rằng các request GET và POST được gửi đến điểm cuối này api/auth/[…nextauth] sẽ được thư viện next-auth xử lý.

Cuối cùng, hãy khởi động lại ứng dụng nextjs của chúng ta. Điều quan trọng cần lưu ý là thư viện next-auth sẽ không hoạt động ngay vào thời điểm này. Lý do là chúng ta vẫn chưa triển khai protected routes để bảo vệ các trang của mình. Chúng ta sẽ khám phá khía cạnh này tiếp theo.

Làm sao để implement Protected Routes với next-auth

Với việc sử dụng middleware của Next.js, việc bảo vệ các routes trở nên rất dễ dàng.

Bắt đầu bằng cách tạo tệp middleware.ts trong thư mục src gốc.

Để bảo vệ tất cả các trang của bạn một cách thống nhất, hãy chèn đoạn mã sau:

export { default } from 'next-auth/middleware'

Ngoài ra, mọi người có thể bảo mật riêng các trang cụ thể bằng cách sử dụng matcher. Ví dụ: chỉ bảo vệ trang chủ và cart sẽ được triển khai như sau:

export { default } from 'next-auth/middleware'

export const config = { matcher: ['/', '/cart'] }

Bây giờ, khi ta truy cập cả hai trang trên localhost của mình, chúng sẽ hiển thị lời nhắc xác thực mời bạn “Sign in with Google” thay vì hiển thị nội dung thông thường:

Tổng kết lại

Trong hướng dẫn này, mình đã đề cập đến các bước cần thiết để triển khai authenticate và được protected trong ứng dụng Next.js của bạn bằng thư viện next-auth với Nhà cung cấp Google.

Với kiến ​​thức thu được ở đây, giờ đây mọi người có thể tự tin phát triển các ứng dụng cung cấp khả năng kiểm soát truy cập an toàn và nội dung được cá nhân hóa dựa trên xác thực người dùng.

Mọi người cũng có thể triển khai thêm trên các mạng xã hội khác, ví dụ như Facebook, Instagram, Apple, …

Mọi người có thể truy cập vào đây để có thể triển khai những nhà cung cấp khác nhé https://next-auth.js.org/providers/

có hàng ti tỉ thứ nằm ở đây chờ đón mọi người đó ^^

Sắp tới mình sẽ ra thêm nhiều blog liên quan tới Frontend hơn nữa, sẽ chi tiết hơn nên mọi người nhớ đón chờ nhé

The post Authentication Google with NextJS and NextAuth appeared first on Tomoshare.

Tại sao lại cần có proxy?

Thay vì kết nối trực tiếp tới server, client gửi request đến proxy để đánh giá và thực hiện những request đó.

• Bảo vệ quyền riêng tư: Proxy có thể được sử dụng để ẩn địa chỉ IP của client, giúp bảo vệ quyền riêng tư của người dùng khỏi các trang web và ứng dụng mà họ truy cập.
• Cân bằng tải (Load balancing): Proxy có thể được sử dụng để phân phối lưu lượng truy cập giữa nhiều server, giúp cải thiện hiệu suất và độ tin cậy của hệ thống.
• Bảo mật (Security): Proxy có thể được sử dụng để lọc lưu lượng truy cập, giúp ngăn chặn các cuộc tấn công mạng.
• Giảm chi phí: Proxy có thể được sử dụng để truy cập các tài nguyên từ xa, giúp giảm chi phí cho doanh nghiệp.

Có 2 loại proxy thường gặp đó là Forward proxy và Reverse proxy.

Forward proxy

• Là một client proxy, hoạt động thay mặt cho các thiết bị clients để gửi yêu cầu đến server.
• Nó nằm giữa clients và Internet, chuyển tiếp các requests của clients đến server thông qua Internet.

Use cases:

• Access control and content filtering: forward proxy kiểm tra các request có hợp lệ hay không để thực hiện forward hoặc block request.
• Log/Monitor request: quản lý và giám sát các request, thường được sử dụng trong môi trường công ty, trường học hay các tổ chức để kiểm soát việc truy cập Internet và bảo vệ khỏi các nội dung độc hại.
• User Privacy: forward proxy nằm giữa client và Internet, nó thay mặt client gửi request đến server qua Internet, có thể che dấu danh tính, địa chỉ IP và bảo vệ quyền riêng tư của người dùng thực.
• Cache responses: giảm độ trễ, tăng performance, tối ưu bandwidth, proxy cache lại response để trả về cho client trong các lần request tiếp theo thay vì request trực tiếp đến server.

Services:

• Squid
• Privoxy
• VPN services
• Cloudflare WARP

Reverse proxy

• Là một server proxy, nằm giữa Internet và server để xử lý các request thay mặt cho server.
• Chúng hoạt động như những servers bình thường. Reverse proxy chuyển tiếp request đến một hoặc nhiều server thật, kết quả sau đó trả về cho client, làm cho client không biết về những server thật nói trên.
• Reverse proxy được cài đặt trong một private network của một hoặc nhiều server, và tất cả lưu lượng truy cập đều phải đi qua proxy này.

Use cases:

• Load Balancing: cân bằng tải, phân bổ lượng truy cập trang web đến các máy chủ khác nhau, nhằm mục đích tăng throughput, giảm letancy, phục vụ số lượng client lớn hơn.
• Security: có thể coi reverse proxy là một Web Application Firewall (WAF), có nhiệm vụ chặn các truy cập khả nghi đến server, làm rate limit, một phần nào đó ngăn chặn tấn công DDoS.
• Cache responses: giảm độ trễ, tăng performance, tối ưu bandwidth, proxy cache lại response để trả về cho client trong các lần request tiếp theo thay vì request trực tiếp đến server.
• SSL encryption/decryption: reverse proxy có thể xử lý việc SSL termination (dừng), giải mã lưu lượng được mã hóa SSL từ client và chuyển tiếp nó đến máy chủ phụ trợ ở dạng không được mã hóa và ngược lại.

Services:

• Nginx
• Apache HTTP
• HAProxy
• CDN services

Điểm khác biệt chính

• Forward proxy:
  • Xử lý request từ client tới Internet.
  • Bảo vệ quyền riêng tư client và lọc nội dung.
• Reverse proxy:
  • Xử lý request từ Internet tới web servers.
  • Performance và security.

Nguồn: https://blog.bytebytego.com

Cảm ơn mọi người đã dành thời gian để đọc 🙇‍♂️

The post Forward proxy vs. Reverse proxy appeared first on Tomoshare.

4. Unlimited Resource Consumption

API không được bảo vệ, dễ bị tổn thương trước số lượng request hoặc payload sizes quá lớn. Những kẻ tấn công có thể sử dụng điều này gây Denial of Service (DoS) cho hệ thống, hoặc brute force attacks để cố gắng authentication.

Lỗ hổng Unlimited Resource Consumption xảy ra khi API không có cơ chế hạn chế số lượng request tới server. Ví dụ chắc năng login bằng số điện thoại và mã OTP được gửi về số điện thoại, sau đó quá trình xác thực được thực hiện thông qua API POST /api/users/otp_verify. Kẻ tấn công sẽ dùng brute force attacks để tấn công API, random OTP từ 0000 -> 9999 để kiểm thử tìm ra OTP chính xác. Ngoài ra kẻ tấn công có thể upload file với kích thước quá lớn hoặc queries phức tạp khiến API gặp phải tình trạng tắc nghẽn và drop requests.

Cách phòng chống:

• Áp dụng chính sách rate-limiting cho tất cả API endpoints. Đặt biệt với những endpoints liên quan đến authentication là mục tiêu hàng đầu của những kẻ tấn công.
• Giới hạn số lượng requests có thể được thực hiện từ một địa chỉ IP hoặc người dùng trong một khoảng thời gian nhất định.
• Sử dụng keys, fingerprints, recaptcha, .. để giới hạn tốc độ requests.
• Giới hạn payload size và độ phức tạp của query.
• Giới hạn số lượng dữ liệu mà một truy vấn có thể truy xuất bằng cách áp dụng các giới hạn về pagination size, or page counts.
• Tận dụng các biện pháp bảo vệ DDoS từ cloud provider (AWS WAF, API Gateway, …).

5. Broken function level authorization

Ở Part I, chúng ta có broken object level authorization là lỗ hổng liên quan đến phân quyền truy cập đến các đối tượng, user1 có thể truy xuất dữ liệu của user2 thông qua thay đổi ID. Còn lỗ hổng broken function level authorization liên quan đến phân quyền các chức năng của hệ thống. Kẻ tấn công phán đoán các API ẩn với những đặc quyền cao hơn và thực thi chúng. Ví dụ kẻ tấn công có thể truy cập đến API /api/users/my_financial_info, bọn chúng phán đoán và thử thay đổi users -> admin truy cập vào API /api/admin/all_info, sự phân quyền yếu kém có thể dẫn đến việc lộ hết các thông tin nhạy cảm của tất cả users.

Cách phòng chống:

• Chia các API endpoints thành các function scope, phần quyền chặt chẽ theo từng scope.
• Kiểm soát truy cập các function trên server không bao giờ chỉ xử lý phân quyền ở phía client.
• Mặc định để deny all access các function. Chỉ cấp quyền với đối tượng cụ thể.

6. Unrestricted Access to Sensitive Business Flows

Khi các API thực hiện một business flow (quy trình đặt vé, mua sản phẩm, ..). Kẻ tấn công nắm được các business này, lợi dụng các API bằng các phương pháp tự động để đạt được mục đích xấu, chẳng hạn như lấy cắp dữ liệu hoặc thao túng dữ liệu thị trường hoặc giá cả.

Một business flow thường gặp và kịch bản tấn công:

• Purchasing a product flow – Kẻ tấn công sử dụng tính năng tự động để mua tất cả hàng tồn kho của một mặt hàng có nhu cầu cao cùng một lúc và bán lại với giá cao hơn.
• Creating a comment/post flow – Kẻ tấn công lợi dụng tính năng bình luận hoặc post bài viết để tự động spam hệ thống.
• Making a reservation – Kẻ tấn công có thể đặt tất cả các chỗ , ngăn chặn người dùng khác sử dụng hệ thống.

Cách phòng chống:

• Cần nắm vững các business flow, hiểu các business flow có thể dễ bị lạm dụng và thêm các lớp bảo vệ bổ sung cho các quy trình này, authentication là required.
• Áp dụng rate-limiting để hạn chế số lượng và tốc độ truy cập.
• Monitor số lượng truy cập API để phát hiện nguồn truy cập đáng ngờ.
• Identify non-human: Xác định xem đó có phải người dùng thao tác không chẳng hạn như kiểm tra giao dịch nhanh bất thường, thiết lập Captcha, human detection,..

Trong ba lỗ hổng trên, ý kiến cá nhân mình đánh giá Unrestricted Access to Sensitive Business Flows là anh em xác suất dính phải cao nhất, còn các anh em khác thấy như thế nào? Tự hỏi admin blog mình có cơ chế nào tránh việc comment spam không ta ?…….

Reference

https://apisecurity.io/owasp-api-security-top-10/

The post Top 10 API Security Vulnerabilities in 2023 (Part II) appeared first on Tomoshare.

1. Broken object level authorization

Sở dĩ Broken object level authorization nằm top 1 là vì hacker không cần sử dụng phương pháp tấn công gì cao siêu, chỉ cần thay thế ID tài nguyên của họ bằng ID tài nguyên thuộc về người dùng khác. Ví dụ như, kẻ tấn công biết được API có dạng /api/shopID/financial_info, chúng thử nghiệm thay thế từng shopID, nếu API không phân quyền user với từng shop thì hacker có thể xem được thông tin của tất cả các shop. Vấn đề có thể trầm trọng hơn khi ID là tuyến tính có thể liệt kê ra được (ID: 1,2,3,..).

Cách phòng chống:

• Thực hiện kiểm tra ủy quyền chặt chẽ với từng API và nên xây dựng hệ thống phân quyền có cấp bậc với từng tài nguyên. Chỉ những user có quyền xem financial_info của shop1ID mới có quyền call API /api/shop1ID/financial_info.
• Không nên dựa vào ID phía client gửi, sử dụng ID được lưu trữ trong session. Thay vì sử dụng /api/shopID/financial_info, ta có thể sử dụng /api/financial_info lấy thông tin shop dựa vào current_user.
• Sử dụng random IDs để kẻ tấn công không thể đoán được (UUIDs – /api/cc20c3ec-1fcc-4912-a0bc-b361d1180b63/financial_info).
• Triển khai test case đầy đủ để ngăn ngừa lỗ hổng này.

2. Broken authentication

Broken object level authorization là lỗ hổng liên quan đến phân quyền, còn broken authentication là xác thực. Xác thực API được triển khai kém cho phép hacker giả định danh tính của người dùng khác hoặc truy cập tài nguyên mà không cần bất kỳ xác thực nào.

Nguyên nhân dẫn đến broken authentication:

• Những internal API không có authentication. Một số API nằm trong private network chúng ta mặc định đã an toàn mà bỏ qua việc xác thực.
• Có cơ chế xác thực nhưng cơ thể xác thực đơn giản, API key yếu, dễ đoán không rotate định kỳ.
• Mật khẩu yếu, plain text, hàm băm kém, mật khẩu dùng chung hoặc mật khẩu mặc định. Một số hệ thống tự động tạo password mặc định nhưng password dễ đoán mà không có chức năng reset password lần login đầu tiên.
• Authentication dễ bị brute force attacks. Brute force attacks là kiểu tấn công mà hacker sẽ cố gắng đoán mật khẩu hoặc các thông tin xác thực khác bằng cách thử tất cả các kết hợp ký tự có thể.
• Thông tin credentials and keys bị lộ trong URLs.
• Cơ chế xác thực yếu, JWT token chỉ decode mà không verify signature (chữ ký).
• Sử dụng token vĩnh viễn, không hết hạn.

Cách phòng chống:

• Kiểm tra tất cả các API đã xác thực chưa, nếu có thì các cách có thể xác thực.
• API cho password reset and one-time links để authenticate cần được bảo mật, có thể đính kèm với one-time verification code.
• Sử dụng những phương pháp tiêu chuẩn có sẵn để generate token (JWT), lưu trữ password và multi-factor authentication (MFA).
• Sử dụng rate-limiting cho việc authentication (quy định hạn mức request authenticate thất bại), thực hiện các chính sách lockout khi có nghi ngờ, kiểm tra password yếu của người dùng.

3. Broken Object Property Level Authorization

API endpoints có thể bị tấn công dựa vào data của chúng (request data, response data): response data tiết lộ nhiều thông tin hơn mục đích business (excessive information exposure), chấp nhận và xử lý nhiều request data hơn mức cần thiết (mass assignment).

Nhiều API trả về toàn bộ dữ liệu thuộc tính của object (user->toJson()), việc lọc dữ liệu cần thiết để hiển thị được hiện bên phía client. Kể tấn công có thể lấy các dữ liệu nhạy cảm, phân tích để biết được các fields của object của database để tấn công mass assignment.

Mass assignment ở đây là cách kẻ tấn công bổ sung thêm các fields nhạy cảm vào request payload gửi lên API. API không lọc dữ liệu đầu vào, permit data, bind toàn bộ params data sang object và lưu object đó vào database. Kẻ tấn công có thể chỉnh sửa thông tin nhạy cảm, thay đổi role người dùng,…

Cách phòng chống:

• Không trả về toàn bộ dữ liệu và dữ liệu phải được lọc ở server trước khi trả về cho client. Chỉ tiết lộ dữ liệu cần thiết để hiển thị phía client.
• Xác định các dữ liệu nhạy cảm và tránh tiết lộ các thông tin này: Personally Identifiable Information (PII – email, phone, passport, Social Security number), Payment Card Industry (PCI).
• Không tự động assign params data tới objects. Cần permit params, payload data, lọc và lấy dữ liệu cần thiết.
• Sử dụng readOnly với những thuộc tính có thể truy xuất qua API mà không bao giờ được sửa đổi.

Trên đây là top 3 lỗ hổng bảo mật hàng đầu ! Thui buồn ngủ rùi hẹn các đồng dâm ở part II nha !

Reference

https://apisecurity.io/owasp-api-security-top-10/

The post Top 10 API Security Vulnerabilities in 2023 (Part I) appeared first on Tomoshare.

The post SQL Injection appeared first on Tomoshare.