Security

1.1
+ password trong DB phải được mã hóa
+ email confirm password: ko nên chứa pass
logs:
+ khi đăng ký tài khoản thì hay gửi email chứa cả password
đăng ký, login, reset password ko được show text ***********
mình nên check cả client, server chạy cái đó ở trên browser, burp check lại
mã hóa ở client=> server site
khi bắt được ở trên burp xác nhận ở client => bình thường tự đăng nhập tự bắt
lại cái reques thì em tự thấy nó đăng nhập
trên server ko mã hóa cái gì??
nó có hiện clear text hay ko
test thêm 1 vài cái nữa có mục đăng ký
kiểm tra email đăng ký thành công nó có show password lên ko?
nếu trong email hiển thị thì là lỗi security
khả năng cao user ko để ý họ dễ forward email cho người khác
bảo vệ được session id cần http only, secure

1.2
điều kiện khi reset password giống như tạo mới password
- min lenght
- special character
- max length: 50
so sánh 2 trang tạo mới password, với change password, random password mình cũng
kiểm tra xem nó có giống rule ko

chương trình có chống brute force or other automated attacks

login sai liên tục lock ip

1.3
khi nhập sai username hoặc password thì ko nên thông báo nhập sai username or
password
nên check ở phía api xem cụ thể như nào
1.4
trang thương mại điện tử thì login sai 2 lần thì lock account
có thể tăng lên 5-10 lần
còn atm thì ít hơn 3-6 lần
cái config thì có thể điều chỉnh
có auto unlock sau 1-2h chứ ko lock luôn
có nhiều chỗ chặn theo ip, có rủi ro cty dùng chung ip thì chặn cả cty đó luôn
nên chặn theo từng user, có thời gian tự động unlock
có thể dùng intruder để gửi nhiều request lên server xem nó có chặn ko?
hạn chế số lần thử login vào trang đó
nên có thời gian time outs
tránh hackers
kiểm tra giới hạn đăng nhập sai hay ko
nó có tự unlock hay ko
sau 30' dùng lại được
tránh hacker dùng tính năng này để lock các user lại
đỡ phải unlock manual tốn thời gian

1.5
password phải có 8 ký tự trở lên
kèm chữ và số
kèm ký tự đặc biệt
kết hợp với 1.4 thì mới bảo vệ được password
không được dùng lại password đã dùng
ko cần reset password
sau 90 ngày thì hệ thống tự thông báo đổi password
==============================làm manual =========tốn 1 ngày thì làm từ ý 1- 5

1.6
không hiển thị password khi nhập các trường password
1.7 việc mã hóa, hoặc authentication thì thực hiện ở server side
các trang web đang dùng framework thì xử lý ở client side
khi gửi request lên thì có tham số permission ko
role=user change to role=admin
thì mình kiểm tra xem user của mình có lên admin ko
#2:
khi đăng nhập vào trang web với role =admin thì nhìn được menu admin
khi đăng nhập vào trang web với role=user thì ko nhìn được menu admin
người dùng có thể chỉnh sửa JS để show cái menu này lên
đảm bảo authentication control thực hiện ở server side
default admin password
tài khoản admin khacs
list ra các acc= admin
confirm ho dùng pass an toàn chưa có 1 master = khác

1.8
- cho nhập pass phức tạp
- ko ngăn chặn độ dài của password
- có min pass =>8 ký tự
- maxlenth ko nên là 15 hoặc 50 ký tự
1.9
không tiết lộ username
với form đăng ký
thì mình xử lý như nào
=> đã gửi link đăng ký thành công đến email do vậy hacker ko biết được email đó
tạo thành công hay chưa
1.10
đảm bảo ko dùng những username/password thông dụng admin/password
nhiều trang họ tạo thành công rồi disable tài khoản thành công đi
họ tạo tài khoản admin khác
1.11
nhiều trang forgot password để block user khác
tại password đang đổi sang giá trị mới
1. trước khi hoàn tất quá trình forgot password thì cái password cũ vẫn login
được và vào được bình thường
1.12
1 số trang đặt câu hỏi bí mật kiểu "bạn sinh ra ở đâu" nên tránh những câu hỏi này
vì hacker dễ dàng tìm kiếm thông qua facebook
bỏ tính năng về câu hỏi bí mật liên quan đến reset mật khẩu
nên hỗ trợ reset mật qua điện thoại nhưng đi đến nước khác thì ko vào được
đặt những câu hỏi bí mật thì ko dùng những câu hỏi quá dễ kiểu như bạn sinh vào
tháng mấy thì hacker sẽ thử từ tháng 1-12 sẽ thành công
qui tắc chung là ko trả lời thật:
bạn sinh ra quốc gia nào thay vì trả lời VN thì chọn quốc gia khác
cái tip là thêm spacing ở đầu hoặc cuối 1234 hacker in ra nhìn và gõ lại cũng
ko được
tính năng khó quá thì sinh ra lỗ hổng khác
2.2
cần tìm trang cần login
thì cần tìm trang required đăng nhập
2.4 những trang nào mà có đăng nhập thì cho user đăng xuất
ví dụ: lúc đăng xuất chỉ hiển thị ở trang chủ thôi thì fail
nhưng user đăng ở trang thanh toán, thì ko tìm được nút đăng xuất họ ko biết nên
họ tắt tab
nên logout thì nên để ở các trang
2.5
session id ko được để lộ ở chỗ nào khác ngoại trừ cookie headers
hoặc nằm ở body
chứ ko được hiển thị lên URL
tránh để lộ session id trên URL
còn việc mình tự nhập vào thì khác
2.6
nếu dùng session thì có thuộc tính này httponly
nó ko liên quan đến http hoặc https
hack-yourself-first.com
/robots.ttxt

sensitive data exposure:

- thông tin liên quan đến username (thấp), password(cả 2 thì cao) của admin
- mã pin: số dạng personal thái id xem là 1 mã pin personal information number
(pin) => high hoặc critical
hoặc làm ứng dụng liên quan đến nhà nước công an để lộ mã cmnd thì cao
ngoài ra thông tin về session, token, cookie thì là nhạy cảm
tùy từng tình huống xem có nhạy cảm ko?
nhiều ứng dụng số điện thoại là nhạy cảm còn 1 số ứng dụng thì là bình thường
- credit card: thẻ tín dụng ngân hàng của người dùng
- customers data: dữ liệu khách hàng ko được public, chia sẻ nó chứa nhiều thông
tin có thể bị spam
- ứng dụng có áp dụng luật, hoặc luật ở cty ví dụ: ứng dụng cho nước mỹ, hoặc
thái thì họ xem thái id như cmnd của mình ko được lộ ra ngoài
+ mức độ ảnh hưởng: độ nguy hiểm dựa vào thông tin bị lộ ra ngoài
ví dụ: để lộ địa chỉ nhà hoặc cmnd severity sẽ cao hơn so với cái tên vì tên có
thể trùng nhau

+ lộ thông tin khó để scan ra vì:

- tool ko biết thông tin nào là quan trọng thông tin nào là ko
- external tester test dạng black bock ko try cập được vào source code nên ko
test được, nhiều khi có lỗi liên quan đến ko mã hóa password trong DB họ ko test
được
- white bock thì họ có quyền database, source code acc admin
- trang web nào đó để lộ thông tin khác hàng hay bị hacker đánh cắp thì mức độ
ảnh hưởng rất cao
- trang 404: http://hack-yourself-first.com/Supercar/Leaderboard1111111
nó thông báo lỗi the resource cannot be found=> test function is OK
but test security họ thông báo là trang ko tồn tại tuy nhiên lại thông báo cho
hacker biết
version information: microsoft.net framework version 4.0., asp.net ver 4.7.
dễ tấn công hơn

- nhập thông tin userprofile/34': http://hack-yourself-

first.com/Account/UserProfile/34
khi nhập paremters invalid value nó trả về trang thông báo lỗi
+ liên quan đến kiểu dữ liệu của userid
version information: microsoft.net framework version 4.0., asp.net ver 4.7.
+ để lộ email của trưởng phòng, nhân viên hacker gửi virus vào email là 1 rủi ro
mình đóng vai trò là người tư vấn để hạn chế rủi ro chứ ko phải người nếu đúng
sai gì cả
- tên của những fodler trên linux server hi/var/value
http://hack-yourself-first.com/robots.txt => chứa nhiều thông tin nhạy cảm như api
folder của admin
- nó hiển thị nginx/1.4.1 => chứa thông tin nhạy cảm version của server
http://hack-yourself-first.com/robots.txt server: microsoft-IIS/10.0
XML để lưu trữ data
trong table hoặc trong file để hiểu được thì follow theo cấu trúc thì mình dùng
XML
SQL chèn data vào DB
=========email=========
<note>
<to>Tove</to>
<from>Jani</from>
<heading></heading>
<body></body>
</note>
họ sẽ nhập mã độc nếu form thực thi được thì lỗi
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection
chỉ áp dụng được với trường hợp trang web sử dụng XML còn ko sử dụng thì dùng
SQL injection
===
cách cấu hình server
1. bật xamp file xamp.control
2. chép thư mực source file giải nén vào htdoc folder: mutillidae\
3. xóa dB password lưu lại file database_config.php
http://127.0.0.1/mutillidae/database-offline.php
D:\xamp\htdocs\mutillidae\includes
lần sau thì ko phải cài gì nữa
chỉ cần bật 2 dịch vụ của xamp đầu tiên lên và vào http://127.0.0.1/mutillidae/ là
okie
== các trang web nên sử dụng phương thức https: chứ ko nên trộn lẫn http
vì http nó không bảo mật
nếu là trang đăng nhập thì respone trả về có đầy đủ httpOnly secure
--==============
hacker có thể sửa
tất cả các request bên bắt và thay đổi lại
khuyến khích id random chứ ko có tăng dần
nếu trang web lỗi thì hacker ko biết id gì ví dụ lần 1: amdsfsdjf123djfjd;
dsfjdfj2323419900
---
cái avartar mà chứa id của mình thì mình thử chỉnh lại lấy id của người khác xem
họ có bị ảnh hưởng ko/
lỗi liên quan đến cấu hình
1. dùng window bản cũ chưa cập nhật security: mỗi ngày software, window có bản cập
nhật nên update hàng ngày ko hacker sẽ tấn công
liệt kê phần mềm mình đang dùng check version xem có lastest ko và đang có lỗi
bảo mật gì ko?
cái hệ điều hành cũ quá hay ko, phiên bản đó có dính lỗi bảo mật ko?
2. các file hoặc folder mình upload cấu hình chưa đúng ví dụ chỉ cho phép admin
chỉ đọc và ghi thôi tuy nhiên lại cấp cho cả user cũng có quyền read và write, có
check đăng nhập mới xem được file ko
wordpress source
3. enable các dịch vụ ko cần thiết, mình ko dùng thì mình disable đi vì ko cập nhật
hay kiểm tra ví dụ: ko dùng port 21 thì nên disable, trang web mình ko dùng add on
thì nên disable hoặc remove
nó là ý tưởng lớn, cái gì mà mình ko dùng thì mình nên disable đi ví dụ: trong
trang web của mình có 2 tài khoản admin thì mình ko dùng cái 2 thì mình hay quên
nên disable
máy server mình ko hay dùng có port 80,81,23
nmap ipaddress-5
cái port giống như cửa, mình chỉ dùng 4 cửa thôi thì những cửa khác nên đóng
lại
có lúc mở lên mà quên ko tắt hacker sẽ cố gắng tấn công vào port
 ví dụ: làm trang web wordpress hay có thêm plugin nếu ko dùng nữa thì nên remove
hoặc disable
1 ngân hàng có 3 cửa mà mở tận 10 cái thì hacker tận dụng tấn công vào 1 trong 7
cửa còn lại
security thì bảo vệ 10 cái an toàn, còn hacker họ chỉ cần tấn công 1 cửa thành
công là được => việc phòng chống khó hơn tấn công
zenmap

4. có những tài khoản mặc định password ko đổi

5. tiết lộ thông tin liên quan đến admin hoặc trang debug đối với link ko tồn tại
404 thì nó xảy ra trang exception do cấu hình sai
khi vào những trang lỗi 404 hoặc sql injection thì
6. SSL liên quan đến HTTPS các trang đều phải dùng https
7. cấu hình sai user permission: role của user, members cấu hình cho đúng quyền
mình có nhiều quyền chồng chéo nhau mình nên kẻ bảng
ví dụ: intitile index of
test 50 folders chung 1 quyền, còn folder đặc biệt check riêng
..CV

...../nam.pdf

..../long.pdf

....hien.pdf
=> quyền chỉ xem nên có chung 1 quyền
trong 1 form có 20 fields thì cần check all fields

application error discosure => trả về trang thông báo lỗi chứa thông tin nhạy cảm
private ip disclosure: => để lộ ip
lỗi liên quan đến cấu hình thì dùng tool
còn lỗi về access control thì cần manual
scan 1 trang tái tạo hết các lỗi tìm được trên trang đó có câu hỏi gì thì dễ hơn
dùng sql map để hack nếu xem được tên database+ tên bảng
thì đã là critical rồi

=== buổi 8 ==========

XSS = Cross Site Scripting vì sao ko viết thành CSS vì dễ nhầm
sinh ra trên ứng dụng web khi validation tốt nếu input
<script>alert('check')</script>
1. common web vulnerabilities
lỗi phổ biến trên ứng dụng web trong nhiều năm chưa được khắc phục hoàn toàn,
khi web bị lỗi thì hacker dễ tấn công
2. diffilcult
khó nhận diện và khắc phục hoàn toàn, mình phải đảm bảo validation ở các
parameters
3. khi khai thác thành công thì có thể đánh cắp session id dùng cái này để đăng
nhập mà ko cần username,password
4. hacker chèn mã độc java script liên quan đến keylog nó ghi lại những hành động
mình gõ từ bàn phím,
5. có thể defacement web kiểu như chèn text trang web của bạn bị hacker

nhóm
1. Reflected XSS: chèn trực tiếp trên URL
mỗi lần tấn công là phải gửi cho user
họ khuyến khích ko nhấp vào link lạ vì họ có thể chèn mã độc vào URL và gửi cho
user dụ họ click vào link
họ tạo ra trang giả mạo, họ đặt iframe với chiều cao, rộng =0 mình ko nhìn thấy
nhưng khi load trang thì nhìn thấy hết
họ dùng link rút gọn kiểu tiny.cc/ass4333ccc nhưng thực ra link họ là
http://127.0.0.1/mutillidae/index.php?page=user-poll.php&csrf-token=&choice=
%3Cscript%3Ealert(123456)%3C/script%3E&initials=1&user-poll-php-submit-
button=Submit+Vote
2. Stored XSS: lưu vào DB ko cần thiết gửi cho user
ko cần gửi cho user mỗi lần tấn công thì thực thi
mình vào trang sản phẩm có mục bình luận tránh hacker nhập mã độc vào
nghĩ cách làm sao chèn mã độc vào DB mỗi lần user vào thì đều thực thi nếu nhấn
vào comment
<script>alert("Hacked 555");</script>
3. DOM based XSS: chèn trực tiếp trên URL với cấu trúc thể hiện HTML trên trang
web cần gửi cho user click vào link
hacker chèn mã html vào trang web sinh ra được 1 form gender trong đó có 2 giá
trị: male, female trong function show thực thi mã độc
để tấn công gửi link này cho user khác
khi user nhấp vào thì hiển thị trang web như này có trường gender user thấy thì
nhấp vào thì thực thi đoạn mã độc: undefined

trong thực tế hacker chèn mã độc ko có pop-up có thể lấy thông tin session,cookie
khi đăng ký tài khoản thành công thì cái address: <script>alert("hacking")</script>
sau khi đăng ký thành công thì chỉ show hello sang
nên sau khi search thì ko thấy
trong trang quản trị, admin xem địa chỉ thì admin bị ảnh hưởng
khi mã độc thực thi thì sẽ đánh cắp được session id của admin
thay vì view source ở trang admin=> view user profile xem address field được mã
hóa chưa? <script>alert("hacking")</script>
hacker sẽ input những cái payload vào
khi test cần test kỹ những field như vậy
có thể dùng tool xsstrike
https://github.com/s0md3v/XSStrike
vì dev cắt <script>
thì hacker sẽ nhập kiểu <sCriPt>
hoặc <<script>script>=> xóa đi thì thành 1 chữ sciprt mới

----A9=========
giống như căn nhà dùng ổ khóa lỗi
thì dễ bị hacker tấn công
list hết component đang dùng thư viện java script gì
version bao nhiêu
dùng thư viện jquery gì và version bao nhiêu
XSS có thể bị version jquery này nhưng được fix ở ở version khác
ví dụ: Jquery libs đang bị lỗi ở ver 2.2.4
recommand update to 3.0.0
https://snyk.io/test/npm/jquery/2.2.4
có thể dùng tools check: https://www.owasp.org/index.php/OWASP_Dependency_Check
mã nguồn mở add on plugin trên web
mình search google xem có bị dính lỗi bảo mật ko
=> update lên version mới nhất có thể dính lỗi bảo mật bản mới nhưng tốt hơn bản
cũ
các tool trả phí đều có thể detect được lỗi này
bản đang dùng là bản gì và đang có lỗi security là gì
9.2 hôm nay có thể update gì thế có thể lên đây xem
https://www.exploit-db.com/
9.3 những cái gì mình ko dùng thì disable nó đi
còn nếu enable nó thì phải quan sát, theo dõi nó
----A10
5.1:
mình sẽ kiểm tra xem ứng dụng có bung ra exception, stack traces
trong những trang log nó sẽ ko để lộ thông tin nhạy cảm liên quan đến session id,
personal information
khi user đăng nhập sai: hệ thống lưu lại user hoặc id thôi chứ ko được track cả
password, id, số tài khoản của user hay ko
facebook để lộ password của người dùng dạng plaintext facebook có mã hóa ko có
trường hợp như vậy
nó xảy ra khi mình lưu log, chứ ko phải DB ko mã hóa
5.2: log control sẽ được thực hiện ở server side, nếu user xóa hoặc mất device
thì mình ko đọc được
cái implement + lưu trữ trên server
những cái logic hoặc cái quan trọng thì thực hiện ở server
5.3 mình sẽ log cả trường hợp success hoặc fail luôn
nếu gặp lỗi thì mới log
đứng ở security thì cần log hết
vì xóa hoặc thêm tài khoản thành công thì mình biết ai là người xóa hoặc thêm
5.4 tất cả các log được protect bằng cách đăng nhập vào vì log chứa thông tin nhạy
cảm thì cần xác thực
ví dụ: mình có trang log mà public ra đó là lỗi liên quan đến bảo mật
5.5 mình kiểm tra xem cái log có chứa thông tin nhạy cảm ko
dev hay log nhiều hơn những thông tin cần thiết
các log lên backup trên cloud tại vì lưu trên local thì khả năng mất rất nhiều
mình có 1 server bị hacker tấn công
thì hacker sẽ tìm cách xóa file log đi
nên mình backup sync online thì dù có xóa vẫn có bản backup
cấu hình sai trên firewall
mình có 1 server trên server có cái firewall mình sẽ cài cho đúng
mình có alert ngay khi bị tấn công kiểu như sms, email khi bị tấn công
các hoạt động trái phép được detect real time
trong A10 có 2 phần quan trọng là log + monitor
log thì mình sẽ check được
còn monitor thì devops sẽ check giúp mình
ngoài việc log acc thì gửi cho user đó 1 sms thông báo
mình sẽ để ý và thay đổi mật khẩu
tuy nhiên Owasp dùng chung cho nhiều tầng lớp level
có người họ là security, dev, research
những issuse này phục vụ nhiều người
khi học thì mình xác định sự ưu tiên và focus vào security test thì tập trung vào
web
level foudation
A1-A3
A5, A6, A7 3 lỗi thông dụng có thể làm được
A9 có thể làm được
còn A4 cũng ít dùng mediun
A8 lỗi sâu cần làm nhiều thứ medium thôi
A10 medium vì monitor vì công việc của devops ít làm
trong A1 cũng có cách tiếp cận khác nhau
hoặc A9 sử dụng những component đã biết
biết cách nhận diện phiên bản nào
search thử phiên bản đó có bị lỗi ko
hoặc có mới nhất hay ko
tuy nhiên senior hoặc research biết bị lỗi giờ làm sao khai thác lỗi đó thành công
các bạn sẽ lập trình các code để khai thác tự động
code tràn bộ nhớ, tràn ram mới sinh ra được lỗi
tại vì 1 lỗi thì tùy vào trình độ đọc ko hiểu ko sao
tự test và tìm lỗi
áp dụng trong công việc thực tế xem có issuse gì ko

https://docs.google.com/document/d/17YNwX8Vw66AZLStJQbUrRs9OxBjzMAGNyZ0rcB2aHHY/edi
t

Xenotix
xsstrike
xsstrike.py -u "http://" --crawl
mình muốn send request đến 1
--header
ngân hàng.com
tự dưng lại điều hướng sang nganhang1.com
nếu mình nhập thông tin sẽ bị mất

testphp.vulnweb.com/listproducts.php?artist=1

===========A10 2013===========
ko validate điều hướng đúng trang
dễ bị hacker điều hướng sang trang của họ
ví dụ:
zero.webappsecurity.com/bank/redirect.html?url=*transfer-funds.html*
zero.webappsecurity.com/bank/redirect.html?url=http://hacker.com
zero.webappsecurity.com/bank/redirect.html?url=http://webappsecurity1.com
http://zero.webappsecurity.com/bank/redirect.html?url=http://webappsecurity1.com
Open Redirect = Unvalidated Redirect
+ đánh cắp thông tin người dùng
+ khi vào trang hacker thì họ thấy giao diện giống nên họ đăng nhập vào fishing họ
lấy cắp thông tin
+ sang trang mã độc, chứa backdo,
+ điều hướng đến các trang bên trong
GET: lan.com/admin/user/deleteUser/*1*
http://zero.webappsecurity.com/bank/redirect.html?url=/admin/user/deleteUser/12
=> cách ngăn chặn
1. hạn chế việc điều hướng URL
mình chèn trực tiếp hyperlink ko dùng cách
url=zero.webappsecurity.com/bank/redirect.html?url=account-activity.html
mình dùng link trực tiếp: zero.webappsecurity.com/bank/account-activity.html
2. cần validate cái input mình có danh sách white list URL tin tưởng thì dùng cách
này chỉ cho nó điều hướng đến white list
white list / trusted url:
account-activity.html
pay-bills.html
mình sẽ kiểm soát được những link nào thì sẽ cho điều hướng

3. khi điều hướng sang trang khác cần có trang notification bạn đang điều hướng
đến trang google.com nếu user click yes thì điều hướng qua, còn ko thì giữ nguyên
tool zap vẫn hiển thị ra được extenal rediect or open rediection
=== A8 CSRF 2013========
ví dụ:
user đăng nhập vào tài khoản thành công
http://zero.webappsecurity.com/bank/transfer-funds-confirm.html
vì trên cùng trình duyệt sử dụng session active
khi hacker gửi cho user 1 link
có 1 nút: sumbit request
1 trang html
view source thì hacker đặt sẵn 1 cái field
<html>
<body>
<form action="http://zero.webappsecurity.com/bank/transfer-funds-confirm.html"
method="POST">
<input type="hidden" name="fromAccountId" value="1" />
<input type="hidden" name="toAccountId" value="1" />
<input type="hidden" name="amount" value="110000" />
<input type="hidden" name="description" value="test" />
 <input type="submit" value="Submit request" />
</form>
</body>
</html>
hacker dẫn dụ người dùng thực hiện những hành động ko mong muốn hoặc ko biết mà
họ đang authenticated
trên trình duyệt đó
kết hợp với 1 số hình thức tấn công, họ gửi link qua chat hay email
họ nói trang này đang khuyến mại
user đã đăng xuất rồi hoặc chưa đăng nhập thì hacker ko tấn công được
thuộc tính csrf chỉ cần cho những request mang tính submit: post, delete
những trang nào tĩnh thì ko cần thuộc tính này
request nào mà cần update thông tin người dùng, sửa xóa dữ liệu thì mới cần
web thì phải cần
vì cách chống lỗi này thì cần thuộc tính csrf
http request cho những put, post, delete
còn những request chỉ xem chữ thôi thì ko cần
giả lập 2 users
1 user hacker
1 user người dùng
hacker gửi cho người dùng file html
cái csrf cần đảm bảo random và độ dài
cái này chỉ áp dụng cho web thôi
còn ko tính cho api
E:\Security\csrf-poc-generator-master

Note:

1. lấy mẫu có sẵn

2. biểu đồ nên lấy mẫu có sẵn dễ hiểu
3. hiện tại mình học thì format cần chỉnh lại
title như này hạn chế dụng
xem mẫu trên mạng
nhìn nó ko được chuyên nghiệp
ko cần màu hoặc phông to

4. file tổng kết hết những gì tìm được

lỗi được nhiều hơn
tải 1 số reports về technical tham khảo
thì sẽ được đẹp hơn chuyên nghiệp hơn
============ Test plan============
3. Test Approach những bước làm về secuirty
+ tìm hiểu về ứng dụng hoặc release đó có 1 dự án release vào tháng 10: khi nào
thì dành thời gian cho performance, secuirty trong lần release đó có những
functions nào nắm được overview về dự án thì làm về test plan
nó là 1 file word chứa tất cả các thông tin cần thiết trong lần release đó
nếu làm ko tốt thì sẽ ko hiệu quả được
+ mình sẽ có 1 planning khác test plan chung cho QA
+ mình sẽ apply kiểu test gì, tools gì cho dự án đó chỉ cần test cho app hay
mobile hoặc server , tools miễn phí hay dùng tools có phí nữa như burp pro
+ chuẩn bị check list security checklist OWzap mình tìm hiểu thêm, thêm các ý vào
checklist
+ bắt đầu exec
+ Report issuse
họ test xong xong luôn security test
họ vừa làm QA + security luôn ko có time để join từ đầu
thời gian test tùy vào từng dự án và đặc tính của công ty
trước mỗi lần release có 2 tuần để test security
họ ko được assign cho 1 project cụ thể
họ ko join được từ đầu họ chỉ join vào thời gian trước 1-2 tuần test security
mình là QA học thêm về security để ứng dụng

* QA (testing + security) <= tham gia từ đầu => tham gia full
* 1 người người security (security tester) => support 3-4 teams
team 1: done
team 2: done
có thể scanner về code luôn
tuy nhiên mình đang học về sản phẩm thì focus vào từ lúc làm sản phẩm rồi
chức năng send OTP ko giới hạn số lần gửi thì cái này liên quan đến bảo mật

design cấu hình sever có bao nhiêu cái server, đặt và kết nối như nào
review code cấu trúc
authentication như thế nào
mình biết được cách nó authentication, token, server như nào thì đóng góp sớm
đưa ra những solution hoặc architech nên có những giải pháp sớm hơn
những cái network, devops cũng có người làm security cho nó

từ những kinh nghiệm đưa ra được những recommand

có tính năng upload hình ảnh
thì validation nên thực hiện trên server site, nên giới hạn file size
mình test api, performance, security

1. mình sẽ có 1-2 tuần để test

cố gắng tấn công xem có để lộ thông tin ko
có đánh giá về bảo mật ứng dụng nó có an toàn ko mức độ bảo mật
đưa ra được những recommand
có đáp ứng được những check list mình đưa ra ko hay fail nhiều
khi test rồi đưa ra được đánh giá sớm trước release
cái report đưa ra những kết quả cho ứng dụng cho web mobile api có an toàn hay ko
hệ thống có nhiều domain hoặc server

Scope
những chức năng test đợt này
+ release 6 tính năng cần test security
mình ko có đủ time, nhân lực để làm việc đó
lỗi liên quan nằm ngoài scope ko chịu trách nhiệm những phần đó
danh sách out of scope
mình ko test ứng dụng ios, mình chỉ test front-end cho user thôi
ko test cho trang admin
mình ko test network, dos
những tools sẽ dùng
1. burp suite pro thì cần mua trước khi test rồi ko đủ time mua
2. zap
3. sql map

Schedule
mỗi lần test thì chỉ có time nhất định ví dụ 1-2 weeks mình sẽ làm những gì
1. chuẩn bị test plan
2. test plan approved
3. test preparation
4. start to test the system

delivery
1. Technical report (bao gồm cả recommand dation)
2. summary thì có thể làm bằng file excel
3. email report đó summary lại + đính kèm technical report
Risk và khó khăn mình làm
1. đến ngày test rồi mà tính năng chưa xong 5 low 1 => 5 high
2. mình cần dùng tools burp nhưng cty ko có điều kiện để mua => risk 4

số liên hệ trong thời gian mình test

gặp lỗi liên quan đến server thì liên hệ ai
hoặc mình support team khác mà ko hiểu SRS thì hỏi dev, QA

Approve
làm xong thì đưa test plan cho manager, team lead để họ biết approve
khi mình test scan, test thì làm server rác hoặc treo
mình test ko inform thì rất phiền
2.

lên plan rõ ràng ngắn thôi

khi plan thì mình phải follow theo
những chức năng + thời gian
mình phải được approve

mình test security ko inform mọi người

đầu tháng 8 mới test bạn scan từ tháng 7 làm hệ thống treo vì file rác team chưa
back up dữ liệu
DB bị rác hoặc server chết thì ko khắc phục được luôn
hoặc khôi phục được thì mất Data
làm đúng thời gian đó
mình đưa vào test plan cũng được tuy nhiên hơi detail

=============Cách apply vào dự án=============

1. Mình sẽ có thể tham gia vào SRS nếu thấy có gặp rủi ro về security
2. trong lúc test chức năng thì có thể test cả security
design back end front end
authentication nhận token như nào
dev giải thích cặn kẽ
mình sẽ tạo ra label security riêng
bốc riêng 1 số check list mang vào làm
PO kinh nghiệm
sửa URL access được link vào admin luôn
sửa những gì
trong request có những tham số liên quan đến role xem có apply role khác ko

mình làm song song

request 1 khoảng time
team có 1 số lỗi liên quan đến bảo mật
chú ý đến security
inurl:index.php?id=
inurl:gallery.php?id=
inurl:post.php?id=
inurl:article?id=

xem sơ lại lý thuyết

input manual trình duyệt
họ google search query:

inurl:article?id=

thêm dấu ' vào sau id=1'

nếu văng ra lỗi SQL thì tấn công được
nếu dùng tools scan thì gửi nhiều request ko hợp lệ lên trang đó
admin sẽ thấy và điều tra
chủ đích đang tấn công thực sự
còn nếu manual 1-2 request thì ko sao
đang tấn công trang nào thì trang đó có hệ thống log
nhất là trang thương mại điện tử
tuy nhiên có những đợt chiến dịch thì track ngắn vẫn bị
chỉ tấn công vào trang mình được phép thôi
sợ mang nhiều rắc rối ko đáng

1. cách connect giữa postman và zap

2. dùng command line để cấu hình jekin

===========thực hành test web site

http://kiemthutudong.com/blog/
- xin tài khoản vào DB xem password có mã hóa ko
- xin tài khoản vào web
- xin tài khoản vào git
bên trong source có file nén gì ko file.bak gì đó để trong đó
- cần làm rõ phạm vi test
ngoài trang user thì có trang admin nữa
mình có cần test bên trong trang admin ko
nếu ko yêu cầu thì mình test cả bên trong

mình thu thập các thông tin để test

để nắm được nhiều thông tin hơn
1. black box mình ko được cung cấp thông tin để tấn công lỗi ít hơn
2. white box mình được xem DB, source code, server lỗi cao hơn

mình có 2 tuần
bước 2 lên plan
mình có ít thời gian quá, ko đủ time để test cấu hình server, bỏ qua cả admin
chỉ test trang user
scope
test admin + user sites
thời gian 2 tuần
bước 3
mình xác định kiểu test: white box cả db, source code, ui

mình xác định tools sử dụng: sqlmap, burp, owzap

bước 4
chuẩn bị checklist + test plan
thêm vài ý check list hoặc dùng nguyên
blockain authentication
session
áp dụng được trên trang này
bước 5
mình test trang front end + back end
mình sắp xếp ưu tiên giữa 2 trang
1 trang back end => medium
2 trang front end => high
bắt đầu scan luôn dùng tool mất 1/2-1 ngày cho máy chạy
mình có server riêng để chạy tools chứ ko cài trên máy của mình
trong lúc máy nó scan thì mang check list verify manual test theo checklist của
mình
trong lúc test thì mình đi từ trên xuống dưới và điền kết quả luôn
xem thử password show ra ở đâu, field pasword, hoặc ở DB nếu ko mã hóa thì report
fail => đánh kết quả fail
nếu trong check list có 4 cái fail thì có 4 tickets issuses tương ứng với mình
đánh fail
sau khi tools scan xong thì mình có kết quả
mình manual verify tất cả kết quả tools trả về nếu valid => report lên jira +
updated vào checklist đó luôn
mình ko gửi trực tiếp từ report cho dev thì có thể bị invalid thì dev sẽ reject
mình cũng đánh passfail vào check list luôn
một lỗi thì rơi vào 1 -2 nhóm xem nguyên nhân gốc của nó là gì
xem trong checklist có ý liên quan đến http only => đánh fail cookie no http only
cần trong các request đăng nhập, xác thực thôi còn các request ko cần đăng nhập
thì ko cần http pnlu
cố gắng test hết trong checklist
nếu còn thời gian mở rộng ra dần dần
XSS liên quan đến 5 trang khác nhau
thì cái nào liên quan đến nhau
lỗi liên quan đến cấu hình, permission thiếu http only họ fix trên server thì tất
cả apply=> log chung 1 lỗi
lỗi directory listing
./file/cv/1/
./file/cv/2/
./file/cv/3/
./file/cv/1000/
mình random check 1 vài cái hoặc scan lại
5 requests bị XSS
ở 5 sites khác nhau thì mình nên tách ra thành các tickets riêng
trong 2 tuần planning, mà chưa có checklist thì ko đủ
tuy nhiên có sẵn template, checklist
tốn 1-2 ngày summary report
test liên tục full time 6-7 ngày khoảng thời gian đủ cho 2 trang
trong lúc test mình report luôn
2 ngày cuối gửi mail báo cáo

mỗi ngày 2-3h

nếu mình report cho khách hàng thì sẽ tốn thời gian 1-2 ngày để làm
mình report trong team thôi thì chỉ cần report tất cả những issuse mình tìm được

mình nên tổ chức meeting chia sẻ bug cho team

vì dev bận task khác họ ko fix
ko nên chỉ gửi mail
số bugs mà mình tìm được thì khá nhiều
ví dụ: thiếu cap cha
trong 1 sprint * họ ko fix được tất cả nên dev chỉ fix được 2-3 bugs thôi => mình
retest lại thôi
mình bắt lại những trang mà mình muốn scan thôi
đỡ tốn thời gian
nếu dev fix hết rồi thì mình làm plan cho sprint lại từ đầu coi như pharse mới

đọc file test report

verify lại học luôn

số lượng lỗi tăng lên dần dần

mình tìm hiểu thêm các tools khác nữa mỗi tools có những cái hay mà cái owap ko
tìm ra được

những link security URL thì mình cần xác thực, login, backup chẳng hạn phải có
login
kiểm tra xem nó có đúng quyền ko

các max field nên set max lenght feedback nếu ko hacker sẽ input để lấy thông tin
nên check ở server site

về character set khi input vào 1 field thì ứng dụng biết được là dạng gì UTF-8,
Unicode cùng mã đó mà chuyển sang Unicode
chuyển sang icon input thử => submit có gây lỗi DB ko
id=
product=
mình dùng intruder

password có được mã hóa trước khi lưu trữ vòa DB mã hóa kiểu gì

http respone content thi xem content type: text/html, charset=utf-8 => web
nếu test api http respone content thi xem content type: json

training 6 buổi
bắt đầu từ như vậy

một căn nhà mở cửa có lỗ hổng

tuy nhiên ko đồng nghĩa có quyền scan
1 đánh giá cao
2 ai cho phép mình scan

vò burp t

https://portswigger.net/web-security?
fbclid=IwAR2l2IZhCiw1rH2QjYwkKB95PPmfRG_SZn2JNxZdqLq9ddt1FkAyP9AwdsQ
https://portswigger.net/kb/issues
https://www.udemy.com/burp-suite/
https://owasp-academy.teachable.com/p/owasp-zap-tutorial
https://www.offensive-security.com/information-security-certifications/oscp-
offensive-security-certified-professional/
bug bounty

https://www.google.com/about/appsecurity/reward-program/
https://www.computerweekly.com/news/252458632/Teen-becomes-first-millionaire-
through-HackerOne-bug-bounties