# Excessive trust in client-side controls
Khi add item vào giỏ hàng, giá của item do user quyết định qua biến price và mình có thể sửa giá thành 1.
# High-level logic vulnerability
Trong request thêm item vào giỏ hàng, nếu mình để số lượng đơn hàng (biến quantity) bé hơn 0 thì tổng tiền thanh toán là số âm
# Interger overflow
# Inconsistent handling of exceptional input
https://www.facebook.com/photo?fbid=824561879692097&set=a.597535815728039
Khi đăng kí, ta điền email submit đến server và server sẽ gửi mail đến email đó để xác thực. Khi server đã xác thực thì sẽ lưu email đó vào database. Khi ta truy cập trang admin thì server sẽ check tên miền của email có phải là @DontWannaCry.com hay không, nếu phải thì cho phép truy cập trang.
Lỗ hổng ở đây là khi đăng kí, độ dài kí tự của email là không giới hạn nhưng khi lưu email vào database thì nó giới hạn chỉ 255 kí tự. Nên ta sẽ điền email có phần tên thật dài, sao cho 255 kí tự đầu của email sẽ kết thúc là “@DontWannaCry.com” và phần này sẽ là subdomain của tên miền server mail của hacker
# Inconsistent security controls
Sau khi đăng kí 1 acc bình thường, server có hỗ trợ chức năng đổi email và chức năng này không yêu cầu xác thực email nên ta có thể đổi thành email bất kì
# Weak isolation on dual-use endpoint
Khi đổi mật khẩu, server yêu cầu 4 param gồm username, current-password, new-password-1, new-password-2. Server sẽ **kiểm tra current-password có đúng hay không**, nhưng nếu param này bị **bỏ trống thì bypass luôn**.

# Insufficient workflow validation
Khi vào thanh toán, client sẽ gửi request "POST /cart/checkout"
nếu thất bại thì chuyển hướng client đến "GET /cart?err=INSUFFICIENT_FUNDS"
nếu thành công thì chuyển hướng đến "GET /cart/order-confirmation?order-confirmed=true".
Việc xác thực thành công hay thất bại nằm ở việc client gửi request đến đường dẫn nào trong 2 đường dẫn trên, chứ không được xử lí ở “POST /cart/checkout”. Vậy nên ta bỏ qua việc gửi request đến “POST /cart/checkout”.
Ta sẽ gửi thẳng đến “GET /cart/order-confirmation?order-confirmed=true” là được.
# Authentication bypass via flawed state machine
**Drop request authentication.**
Sau khi đăng nhập, gửi request đến "POST /login" thì server trả về Location đến "GET /role-selector", khi user gửi request đến "GET /role-selector" thì server sẽ đưa user vào danh sách cần check roles trước khi có thể thực hiện bất kì hành động gì. Vậy nên mình chỉ cần không gửi request đến "GET /role-selector" là được.
# Flawed enforcement of business rules
Khi mua đồ, sẽ có array lưu danh sách các mã giảm giá đã áp dụng vào giỏ hàng. Thường thì khi áp thêm mã giảm giá mới thì server cần check mã giảm giá này đã có trong giỏ hàng hay chưa. Tuy nhiên ở đây, server chỉ **so sánh mã hiện tại với mã được áp vào giỏ hàng gần nhất**, cùng mã thì error, khác mã thì accept. Nên chỉ cần có **2 mã giảm giá là luân phiên áp vào giỏ hàng vô hạn lần**.
# Infinite money logic flaw
Idea: add item + discount ticket -> return item + 3$
Có item tên là "gift card", item này có giá 10$ và khi mua item này thì nó trả về 1 gift code, nhập gift code này thì ta có lại 10$ .
Nghe thì có vẻ hòa vốn nhưng lợi dụng việc khi mua ta có thể áp mã giảm giá 30%, nên sau các bước này thì ta lời 3$ và số lượng mã giảm giá là vô hạn, nên ta sẽ chạy tự động tác vụ này.
**Dùng marco trong burpSuite để thực hiện chain này**
# Authentication bypass via encryption oracle
Khi đăng nhập mà có lựa chọn stay-logged-in thì server sẽ cấp cho 1 cookie, nội dung của cookie này đã bị mã hóa.
Khi mình thử xài trang web thì phát hiện ra khi gửi form comment thì nó sẽ check email, nếu email không hợp lệ thì server tạo cookie ‘notification’, cookie này cũng đã được mã hóa, sau đó server chỉ dẫn Location cho browser truy cập lại vào bài post (method GET), thì cookie "notification" được giải mã ở server và gửi về phản hồi có nội dung thông báo email không hợp lệ.
Ta sẽ có nghi ngờ có khi nào server **dùng chung 1 hàm mã hóa cho cả 2 cookie** ‘stay-logged-in’ và ‘notification’ không?
Tiến hành kiểm chứng bằng cách gửi comment có email là giá trị của biến 'stay-logged-in' (lúc này là user wiener) thì nhận được phản hồi là:
Đúng như dự đoán, mặc dù ta không biết hàm mã hóa ở server hoạt động thế nào nên ta không thể tự giải mã cookie 'stay-logged-in'. Nhưng server lại **cung cấp API giải mã** thông qua phương thức GET đến bài post bất kì với cookie 'notification' và API mã hóa thông qua việc gửi comment lỗi để nhận về cookie 'notification'
Dựa vào phản hồi trên, ta dễ dàng biết cấu trúc của cookie 'stay-logged-in' là tên user + thời gian được cấp cookies.
Vậy ta sẽ gửi comment với trường email là "administrator:1712658655731"
Nhận được phản hồi, giá trị trong cookie 'notification' là mã hóa của chuỗi "Invalid email address: administrator:1712658655731"
Sau khi thử nhiều giá trị khác nữa thì nhận thấy 'notification' luôn có phần đầu của chuỗi giống nhau, liệu rằng plaintext được tách thành nhiều khúc trước khi mã hóa? Ta thử xóa 1 vài kí tự trong cookie 'notification', vì đây là dạng base64 nên ta cần chuyển nó về dạng hex, xóa bớt vài kí tự (mỗi kí tự ascii là 2 kí tự trong hex) rồi chuyển nó về lại base64. Thì nhận được thông báo rằng số kí tự phải là bội của 16 mới có thể giải mã. Dựa trên 2 dữ kiện này ta đoán hàm mã hóa tách plaintext thành từng khúc 16 byte để mã hóa thành 16 byte cypher, nếu khúc cuối của plaintext thiếu byte thì nó tự thêm pad cho đủ 16 byte
Để kiểm chứng, ta thử đổi cypher của chuỗi “"Invalid email address: administrator:1712658655731" về hex, xóa bớt 32 kí tự hex (là 16 kí tự ascii), thử gửi đến server để giải mã thì ta nhận được chuỗi "dress: administrator:1712658655731"
Điều này xác thực những gì mà ta dự đoán.
Vậy ta chỉ cần điền thêm 9 kí tự trước chữ 'admin', khi mã hóa nó sẽ là cypher của chuỗi “Invalid email address: xxxxxxxxxadministrator:1712658655731” tổng cộng có 32 kí tự trước kí tự ‘admin’, tương đương với 2 khúc mã hóa và phần sau sẽ là phần mã hóa của “administrator:1712658655731”
Dùng chuỗi này để gắn vào cookie ‘stay-logged-in’ để đăng nhập.