# Edutalk
## 0. Lý do
Cá nhân :D
## 1. Tìm các trang web của Edutalk
Dùng google cái ra ngay :D

Sau khi em mò thử vào trang nội bộ thì dùng extension `wappalyzer` thấy dùng VueJS, Apache nên đoán có thể khai thác qua API + token.
Đăng ký thử tài khoản và hệ thống chuyển sang màn hình cập nhật thông tin. Em thử ngó riêng API thì thấy luôn API show info.
Thử thay ID khác thì ra luôn -> báo luôn chị Thư.
Lúc sau em thấy fix, thử truyền thêm token thì vẫn thấy get bình thường, thay ID vô tư :D (Cách lấy token thì cứ F12 lên thôi)

Sau một hồi dạo chơi thì chị Thư bảo update được bản ghi bất kỳ sẽ được mời cafe nên quyết tâm lên cao, tìm cách mò API khác để update :D
## 2. Tìm cách update dữ liệu
1. Ban đầu em theo hướng đi sâu vào con nội bộ, thế là viết tool scan tìm user có pass mặc định `123456` để mò vào ngó nghiêng :D
Đoán Edutalk backend Laravel (nhìn tên các trường `timestamps` và các trường khác phía sau nên có thể do migration viết thêm vào ^^). Edutalk xài PHP nên cũng code PHP luôn cho đồng bộ:

Chạy được khoảng vài ~~chục~~ user thì đã thấy ngay 1 user :D Tiếc là user không có quyền nên login vào thấy mỗi màn hình update profile. Cay...
2. Mày mò 1 hồi e quyết định thử các hệ thống khác bằng cách scan DNS.

Thấy ngay con Admin có vẻ đầu não nên vào thử. Login bằng user ở bước 1 thì thấy có mỗi cái dashboard có html không, đoán con này đang xây dựng nên lại out ra. Thử tiếp con EduCenter thì bị báo không có quyền. Cay tập 2...
3. Nghĩ đi nghĩ lại, cafe trước mặt rồi mà không được uống nên suy luận lại, em thấy con admin có phần cập nhật thông tin nên dùng thử, update thử thấy user id xuất hiện trên url nên thử update luôn cho user id = 1 (vì id = 1 thường nguy hiểm :D).
Update theo name và email ăn ngay nhá

Đến đoạn này thì win kèo với chị tui rồi, nhưng lại máu me làm quả vào trang đầu não cho hoành tráng... Biết đâu lại lấy le được với em gái nào bên Edutalk ^^
p/s: Nhìn thấy models Apps/Models/User thì chắc mẩm là laravel thật rồi :D
4. Với kinh nghiệm n năm chinh chiến với laravel, tư duy dev sẽ allow update các trường thông tin có trong `fieldable` mà không check theo từng api nên mò thử. Ban đầu update `password` với chính user đang nắm token thành `12345678` thì ăn ngay nên quyết định update luôn `password` cho `user id = 1` (Chứ API đổi pass thì nó bắt có pass cũ nên em chịu ạ :D)
5. Mò vào admin thì gửi ngay ảnh khoe với chị tui, mong chị tui suy nghĩ lại về các đề nghị của tui ạ ^^
## 3. Nhận xét và đóng góp
### Tồn tại
- Các API chưa check quyền của từng user và mới chỉ đơn giản là check xem token có đúng của 1 user nào đó không.
- Frontend đang không xác thực token, userid với server, sửa id trong localstorage là load luôn profile với user id đó.
- Menu cũng đang được render bằng permission lưu trên localstorage. Điều này rất nguy hiểm vì user bình thường nếu sửa biến permission trong localstorage là có full quyền.
### Đề xuất
- Mỗi request qua backend đều cần xác thực `role` và `permission` trên server.
- Không sử dụng userid trực tiếp trên localstorage mà cần qua access_token để server xác thực và tự get userid của token đó.
- Giới hạn phạm vi resource mỗi user có thể truy vấn.
- Trong các API nên transform lại data tránh trả về các thông tin không cần thiết (ví dụ `"model_type": "App\\Models\\User"`)
- Các API insert, update cần rà soát để chỉ update các trường cần thiết (thực tế, đã một số trường hợp update luôn role_id thành admin luôn)