Bản mật nhập môn - Bảo mật cơ bản cho developer

Bản quyền tại toidicodedao.com


Bản mật nhập mơn – Phạm Huy Hồng

1

L i tựa
Bảo mật là một vấ àđề rất tốn kém và phức tạp. Gầ à hưàhệ thố gà oà ũ gà àlỗ hổng (cả
phần mềm lẫn phần cứng), các hacker có thể thông qua các lỗ hổ gà àđể tấn công hệ thống.
Việ à đảm bảo hệ thống bảo mật là trách nhiệm của rất nhiều bên: Sysadmin, network,
manager và developer. Trong phạm vi sách, mình sẽ cùng các bạn tiếp cận khía cạnh bảo
mật dưới góc nhìn của một developer.
Những kiến thức trong ebook này cô cùng ơà ản, dễ học, hư gà h g sẽ vơ cùng hữu ích,
giúp bạn tránh phải những sai lầm bảo mật gớ ngẩ ,à ơà ả àkhià ode.àD à hoà ạn code C
hay C++, Java C# hay PHP, bạ à ũ gàsẽ họ àđượ à iàđiều bổ ích qua series này.
Trách nhiệm của developer là phảiàđảm bảo rằng code mình viết ra sẽ khơng có lỗi bảo mật.
Trong ebook
,à h gàtầđ gà aiàha ke àđể tấn cơng hệ thống mình viết.àTh gà uầđ ,à
chúng ta sẽ cùng tìm hiểu về những lỗ hổng bảo mậtàthường thấy khi code và tìm cách vá lỗi.
Đầphần các lỗi bảo mật ơà ản đ àđượ à gă à hặn trong các framework. Tuy vậy, nhiều trang
web vẫn bị dinh một số lỗi vì sự …à gớ ngẩn hoặ àsơàsuất củầ h hàde elope .àDồđ ,àh àđọc
kĩàe ook và cố gắng áp dụng những kiến thứ à à oà odềđể tránh dính các lỗi này nhé.
Đ àl àse ies hướng dẫn bảo mật cho developer, không phải là hướng dẫn làm hacker. Kiến
thức trong ebook giúp bạn code, giúp bạn vá lỗi chứ không giúp bạn tấn công hệ thống khác
hay lừầđảồ gười dùng. Bạn nào nghiêm túc muốn tầ àsưàhọ àđạo về bảo mật có thể tìm
thánh bảo mật Juno_okyo nhé.

C nh báo
T ước khi dạ à ,àsưàphụ luôn dặ à àđồ đệ rằng: Họ à àl àđể ường thân kiện thể, hành
hiệpà gi pà đời, không phảià để đià ắt nạt kẻ yếu.à T ước khi bắtà đầu sách,à

hà ũ gà uốn
khuyên các bạ àđiềuàtươ gàtự: Học về se u it àđể xây dựng hệ thống bảo mật tốt hơ ,àđể
gi pàđỡ hệ thống khác, chứ không phảiàđể điàha kàha àph àhoại.
V àlýàdoàđạoàđức, nếu phát hiện lỗi trong các hệ thống khác, các bạn nên thông báo cho quản
trị chứ đừng nên phá hoại. Ranh giới giữaà t àhiểu lỗ hổ g à à ph àhoại hệ thố g à à o gà
manh lắm. Với các hệ thống quan trọng. bạn có thể bị truy tố để vào tù bóc lịch cho lỗ ass nở
hoa chứ chẳ gà hơi.

Bản quyền tại toidicodedao.com


Bảo mật nhập mơn – Phạm Huy Hồng

M cl c

PHẦN 1 – BẢO MẬT NHẬP MÔN .................................................................... 4

GIAO THỨCàHTTPà BẢO MẬT àĐẾN MỨC NÀO? ............................................................. 5
Ôn lại về HTTP ....................................................................................................................5
“ơàlược về Man-in-the-middle attack ................................................................................5
Cách phòng chống ..............................................................................................................6
Lưuàý...................................................................................................................................7
Tổng kết ...........................................................................................................................10
LỖ HỔNG BẢO MẬT XSS NGUY HIỂMàĐẾN MỨC NÀO?................................................. 11
Giới thiệu về XSS ..............................................................................................................11
Những dạng XSS ...............................................................................................................11
Cách phòng tránh .............................................................................................................13
Lời kết...............................................................................................................................14
LƯUàTRỮ COOKIE – TƯỞNG KHÔNG HẠI AI NGỜ HẠIàKHÔNGàTƯỞNG ......................... 15
Cookie – Chiế à

hà ui à àhại? ...................................................................................15
Bánh qui nho nhỏ,àđầy những lỗ to to .............................................................................15
Cách phòng chống ............................................................................................................16
SQL INJECTION – LỖ HỔNG BẢO MẬT THẦN THÁNH .................................................... 17
Tại sao SQL Injection lạià thầ àth h ? ...........................................................................17
Hậu quả của SQL Injection ...............................................................................................17
Tấ à gà“QLàI je tio à hưàthế nào? ..............................................................................18
Cách phòng chống ............................................................................................................18
Kết luận ............................................................................................................................19
INSECURE DIRECT OBJECT REFERENCES – GIẤĐẦLỊIàĐI ..................................... 20
Lỗi gì mà tên dài rứa??.....................................................................................................20
Cách lợi dụng lỗ hổng ......................................................................................................20
Cách phòng chống ............................................................................................................22
CSRF – NHỮNG CÚ LỪA NGOẠN MỤC ......................................................................... 23
Cơà ản về CSRF ................................................................................................................23
Các kiểu tấ à gàthường gặp .........................................................................................23
Lưý.................................................................................................................................25
Phịng chống cho website ................................................................................................26
Tổng kết ...........................................................................................................................26
ẨN GIẤU THƠNG TIN HỆ THỐNG – TRÁNH CON MẮTàNGƯỜIàĐỜI VÀ KẺ XẤU ............... 27
Thơng tin hệ thống là gì? .................................................................................................27
Ch gàtầđể thơng tin hệ thố gà hớ h h à hưàthế nào? ..............................................27
Những hậu quả của việ à lộ h g ..................................................................................29
Giấuà hưàthế ồ hồđ g? ...........................................................................................29
QUẢNàLÝàNGƯỜI DÙNG – TƯỞNG DỄ ĂNàMâàKHƠNGàĐƠNàGIẢN ................................ 30
Úi giời!àĐă gàk àđă gà hập có gì khó? .............................................................................30
Quan trọng nhất – Kh gàlưuà ật khẩu! .........................................................................30
Làm thế oàkhià gười dùng quên mật khẩu? .................................................................31
Chống việ àđo à à ật khẩu ........................................................................................31

Bản quyền thuộc về />
2


Bảo mật nhập mơn – Phạm Huy Hồng
Những biện pháp nho nhỏ tă gà ường bảo mật .............................................................32

PHẦN 2 – CASE STUDY.................................................................................. 33
LỖ HỔNG BẢO MẬT KHỦNG KHIẾP CỦA LOTTE CINEMA............................................... 34
Đă gà hập hả? Chỉ cần một bảng User, hai cột Username và Password là xong............34
Vậ à àh aàl àđược chứ gì, lắm trị!! ..............................................................................34
Ối giời phức tạp thế, cùng lắm thì lộ password trên trang của mình thơi mà ................35
Lỗ hổng bảo mật khủng khiếp của Lotte Cinema ............................................................36
TÔI Đá̃ HACK TƠIàTá̉ àWEB SITE CỦ áàLOTTEàCINEMáàNHƯàTHẾ Ná̀ O? ........................ 37
Giớ i thi ̣u .........................................................................................................................37
Bắtàđ ̀ u câu cá ..............................................................................................................37
Câu nh ̀m …à cá m ̣p ......................................................................................................39
Bonus thêm cá voi ........................................................................................................39
K ́t lu ̣n ............................................................................................................................41
Update (30/08/2016) .......................................................................................................42
LI.VNàĐÃà VƠàÝ àĐỂ LỘ DỮ LIỆU 2 TRIỆNGƯỜIàDÙNGàNHƯàTHẾ NÀO?.................. 44
Dị tìm từ web ..................................................................................................................44
Đến app mobile ................................................................................................................45
Quá trình xử lý lỗi.............................................................................................................47
Nhận xét ...........................................................................................................................47
Thay lời kết ................................................................................................................ 49
Về tác giả .................................................................................................................... 50
Thông tin liên lạc: ....................................................................................................... 50

Bản quyền thuộc về />

3


Bảo mật nhập mơn – Phạm Huy Hồng

PHẦNà à–àBẢMẬTàNHẬPàMƠN
Kiến thứ à ơà ản về bảo mật và một số lỗ hổng bảo mậtàthường gặp

Bản quyền thuộc về />
4


Bảo mật nhập mơn – Phạm Huy Hồng

GIAO THỨC HTTP “B O MẬT” Đ N MỨC NÀO?
Ôn lại về HTTP
HTTP là một giao thứ àd gàđể truyền nhận dữ liệu (Xem thêm ở đ ). Hiện tại, phần lớn dữ
liệuàt àI te etàđềuàđược truyền thông qua giao thức HTTP. Các ứng dụng Web hoặc Mobile
ũ gàgọi Restful API thông qua giao thức HTTP.
Tu à hi ,à hượ àđiểm của HTTP là dữ liệuàđược truyề àdưới dạng plain text, không hề được
mã hoá hay bảo mật.àĐiều này dẫ àđến việc hacker có thể dễ dàng nghe lén, chơm chỉa và
chỉnh sửa dữ liệu.à Người ta gọi kiểu tấn công này là Man-in-the-middle attack, viết tắt là
MITM.

“ơàlược về Man-in-the-middle attack
H àtưở gàtượng bạ àđa gàt àtỉnh một em gái dễ thươ gà ặt cute ngực to dánh khủng tên
Li h.àĐể tă gàt hàl gà ạn, bạn không nhắn tin mà trực tiếp viếtàthưàgửi cho nàng. Lúc này,
bạn là client, bé Linh là server, việc gửiàthưàl àgiaồthức HTTP.
Đươ gà hi ,àhoầđẹp thì lắm ruồi bu. Có một thằng hacker xấu xa bỉ ổi tìm cách phá rối bạn,
ta tạm gọi thằng này là Hồng cờ hó.

Search Linh phát nó ra con bé Linh l ộ lipà

+àlu

….

Thằng Hồng cờ hó có thể phá rối bạn bằng những cách sau:
.à“ iffàpa ketàđể đọc lén dữ liệu
Bạn hí hửng bỏ thưà ồh àthư,à hờ bứ àthưà a àđến chỗ Li h.àThưàđa gàt àđường tới,
thằng Hoàng bắtàđược, mở bứ àthưà aà e ,à iếtàđược hết những lời tâm tình ủ ê mà bạn dốc
cạn tấm lịng ra viết.
Trong thực tế, khi bạn gửi username, password qua HTTP, hacker có thể dễ dàng chơm
username, password này bằ gà hàđọc lén các packet trong mạng. (Bạn gửi clip 18+ thì nó
ũ gà h àđược nốt).
2. Sửầđổi packet
Khơng chỉ đọc trộm, thằng Hồng cờ hó kia cịn có thể sửầthưà ủa bạn. Bạ àkhe àLi hàđẹp
hưàMa iaàOza aàth à àsửa thành Happy Polla. Linh reply lại, hẹn bạ àđià h à ghỉ lúc 5h thì
nó sửa thành 5h15.

Bản quyền thuộc về />
5


Bảo mật nhập mơn – Phạm Huy Hồng
Bạn vẫn khơng hay biếtàthưàđ à ị tráo gì cả.àĐế àl àđọc xong, 5h15 ra nhà nghỉ th àđ àthấy
thằng cờ hó và Linh tay trong tay dắt nhau ra. (Thằng H yếu sinh lý nên 15p là xong, các bạn
nên thông cảm cho nó).
Trong thực tế, hacker có thể tha àđổi nội dung bạn nhậ àđược từ se e ,àl àtha àđổi thông
tin hiển thị trên máy bạn. Cả àt ường hợpà àđều khá nguy hiểm vì bạn khơng hề biết mình

bị tấn công.

Kiến thức này thuộc dạ gà à gà ơà ản, nhiề gườiàđ à ià ồi nên mình sẽ khơng giải thích
kĩà ề khía cạ hàkĩàthuật. Các bạn có thể tự tìm Google tìm hiểu them.

Cách phịng chống
Các giải pháp chống MITM trong mạ gàLáNàthường do SysAdmin hoặc các bạn chuyên bảo
mật lo, thông qua việ à iàđặt thiết lập hệ thống. Là developer, cách phòng chố gà ơà ản nhất
chúng ta có thể làm là sử dụng giao thức HTTPS cho ứng dụng, bằng cách thêm SSL Certificate.
Dữ liệu giao tiếp qua HTTPS đ àđược mã hố
à gười ngồi khơng thể đọc trộm hay chỉnh
sửầđượ .àC hà àtươ gàtự hưà iệc bạn và Linh viết mail cho nhau bằng teencode, thằng
Hồng cờ h àkiầ àđọc trộ à ailà ũ gàkh gàhiểu hay sửa thưàđược.
Tu àđộ bảo mật của HTTPS vẫ à hưầphải là tuyệtàđối, nó vẫ à aồhơ à hiều so với chỉ dùng
HTTP thuần. Ngoài ra, nếu trang web của bạ à hưầthể tích hợp https, bạn có thể tích hợp
chứ à ă gàđă gà hập thơng qua Facebook, Google. Tuy hacker vẫn có thể chơm cookie của
gườiàd g,à hư gà tà ầhọ khơng bị lộ username và password.

Bản quyền thuộc về />
6


Bảo mật nhập mơn – Phạm Huy Hồng

Lưý
Hiện tại nhiều trang web vẫn sử dụ gà httpsàgiả cầ à– chỉ sử dụng https ở những trang login và những trang có dữ liệu nhạy cảm. Cách làm này vẫn tồn tại khá nhiều nguy hiểm. Hiện
tại, mình sử dụ gàFiddle àđể demo ở local. Tuy nhiên, hacker có thể làm các trị này khi dùng
chung LAN/WLAN với bạ .àDồđ ,à ần hết sức cẩn thận khi dùng wifi chùa/wifi công cộng nhé.
Ví dụ 1 – Lazada
Phầ à đă gà hập của trang này dùng https, do vậy mình khơng thể s iffà được username,

password.

Dữ liệu truyề à uaà““Làđ à ị mã hố nên khơng thể đọ àl

Bản quyền thuộc về />
àđược

7


Bảo mật nhập mơn – Phạm Huy Hồng
Tuy nhiên, các trang khác của lazada vẫ àd gàhttp.àKhià gười dùng vào các trang này mình
có thể h àđược cookie, sử dụng cookie này để đă gà hậpà hưàthường.

D

D

gàFiddle àđọc lén cookie

gàEditThisCookieàđể du pà ookiề

Ng à ưa,àkhiàFa e ookà hưầd gàhttps,àtụià
account facebook củaà gười khác.

Bản quyền thuộc về />
àđă gà hậpà hưàthường

hà ũ gàd

gà

hà

àđể s iffà àđă gà hập

8


Bảo mật nhập mơn – Phạm Huy Hồng
Ví dụ 2 – Ngân hàng ACB
Lần này mình sẽ lấy trang web của Ngân hàng ACB ra làm ví dụ. Trang này có sử dụng HTTPS
cho trang giao dị h,à hư gàt a gà hủ vẫn là HTTP.

Link ngân hàng trực tuyến dẫ àđến online.acb.com.vn

Mình có thể sửầpa ketàđể dẫ à gười dùng tới trang lừầđảo.

Đoạ à odề

àđổi nội dung HTML mà client nhậ àđược

Bản quyền thuộc về />
9


Bảo mật nhập mơn – Phạm Huy Hồng

Đườ gàli kàđ à ị đ

hàt

ồ

à lie tàkh

gàha à i ết gì

Một số t ường hợpàkh ,àt a gà e àd gàHTTP“à hư gà ẫn tải hình ảnh, javascript, css qua
http. Hacker vẫn có thể dễ dàng sửa nội dung javascript, trộm cookie hưà thường. Doà đ ,à
Google khuyến cáo sử dụng https cho toàn bộ các trang và các link chứ đừ gàđể kiểu giả cầy
hưàthế này nhé.

Tổng kết
Hiện tạiàCh o eà ũ gàđa gà àkế hoạch thị
àt a gàHTTPàl àkh gàa àto àđể cảnh báo cho
gười dùng. Ở những phiên bản sau, bạn sẽ thấy chữ Notàse u e àt àtha hàđịa chỉ nếu
trang web chỉ sử dụng HTTP.

Haiàđiều quan trọng nhất về HTTP rút ra từ bài viết:




HTTP không an tồn hay bảo mật. Tuyệtàđối khơng bao giờ submit thơng tin quan trọng
(mật khẩu, số thẻ ngân hàng) qua HTTP!
Sử dụng http dể duyệtà e à ũ gàgiố gà hưà ện gái mà khơng cần BCS. Nhiều khi dính
bệnh chết lúc nào chẳng biếtàđấy!

Bản quyền thuộc về />

10


Bảo mật nhập mơn – Phạm Huy Hồng

LỖ HỔNG B O MẬT XSS NGUY HI M Đ N
MỨC NÀO?
Giới thiệu về XSS
XSS (Cross Site Scripting) là một lỗi bảo mật hoàph pàha ke à h gà àđộc (javascript) vào
một trang web khác. Hacker có thể lợi dụ gà à độ à
à để deface trang web, cài keylog,
chiếm quyề àđiều khiển củaà gười dùng, dụ dỗ gười dùng tải virus về máy. Các bạn có thể
xem thêm demo trong vụ hack Lotte Cinema t ướ àđ .
Đ àl à ột trong những lỗi bảo mậtàthường gặp nhất trên các trang Web. Các hệ thống từ lớn
đến nhỏ hưàFa e ook,àT itte , một số forum Việt Nam,à… đều từng dính phải lỗi này. Do
mứ àđộ phổ biế à àđộ nguy hiểm của nó, XSS lu àđược vinh dự được nằm trong top 10 lỗi
bảo mật nghiêm trọng nhất trên OWASP (Open Web Application Security Project).

Để tóm tắt, xin trích dẫn vài câu của thánh bảo mật Juno_okyo, gười vừa hack 3 triệu tài
khoản củầse e àXà ồđ .
"Ờ thì ghe cũ g có vẻ nguy hiể
XSS thế? Rảnh quá hả!?"

đấ , hư g sao tôi thấy ông hay viết về

À... một lỗi vừa phổ biến, nằm top 10 OWASP, lại vừa nguy hiểm, có thể kết
hợp tốt với các lỗi khác. Như g dễ tìm, dễ fi , đã thế cị được tính bug
bounty nữa.

Những dạng XSS

T ướ àđ ,àX““àthường nhắm vào code render HTML từ phía Server, ta gọi là Server XSS. Hai
dạ gà“e e àX““àthường gặp là Persistent XSS và Reflected XSS. Ở đ ,à
hàsẽ lấy một thanh
niên tên Khoa ra làm ví dụ. Khoa là một sinh viên ĐHàFPT, là fan của blog t iàđià odềdạo, thích
lên thi* diaàđể t àđịaàđiểm mátxa.
1. Persistent XSS
Trên forum thi*ndia, khi bạn post một comment vào topic, server sẽ lưuà o
e tà ạn post
và hiển thị dưới dạ gàHTML.àKhiàKhoaàpostà E à uốn tìm JáV ,àse e àsẽ lưuàlại và hiển thị
hưàsau:

Bản quyền thuộc về />
11


Bảo mật nhập mơn – Phạm Huy Hồng

Tuy nhiên, Khoa lại không hiề àl hà hưàthế. Do mới học về XSS, Khoa không nhập text mà
nhậpà gu àđoạn script ale t XXX vào khung comment. Lúc này, HTML của trang web sẽ
trở thành:

Trình duyệt sẽ chạy đoạn script này, hiển thị cửa sổ ale tàl .àKhoaàđ à h àđượ à àđộc vào
thi*ndia, thực hiện tấn công XSS thành công. Lưuàý:àM hà hỉ ví dụ thơi, thi*ndia khơng bị lỗi
X““àđ h , các bạn không nên thử).
Trong kiểu tấ à gà ,à àđộc đựợ àlưuàt o gàdatabase trên server, hiển thị ra với tồn bộ
gườiàd g,àdồđ àtầgọi nó là Persistance XSS. Bất kì ai thấy comment củầKhoầđều bị dính
àđộ à ,àdồđ àkiểu tấn cơng này có tầm ả hàhưởng lớn, khá nguy hiểm.
2. Reflected XSS
Với cách tấn công này, hacker ch à àđộ à oàU‘Làdưới dạ gà ue àst i g.àKhià gười dùng
g oà gơà hấp vào URL này, trang web sẽ đọc query string, e de à àđộc vào HTML à gười

d gà d hà ẫ .

Quay lại vớiàKhoa.àDoà i àđịa chỉ
tà aàho ià hư gàkh gàđược share, Khoa cay cứ, quyết
định trả th à àđ àa h.àKhoaà
àgửiàđường mộtàđường link giả JáVà oà ailà àđ àa h.à
Nộià du gà đường link: http://thi*ndia.com?q=<script>deleteAccount();</script>. Khià à đ
anh click link này, họ sẽ oàt a gàthie dia.à“auàđ àse e àsẽ render <script>deleteAccount();
</script>, gọi hàm deleteAccount t o gàJa a“ iptàđể xoá account của họ.
Tầm ả hàhưởng của ReflectedXSS không rộng bằ gàPe sista eàX““,à hư g mứ àđộ nguy hiểm
l àtươ gàđươ g.àHa ke àthường gửiàli kà à àđộc qua email, tin nhắ ,à…à àdụ dỗ gười
d gà li kà o.àDoàđ à à ạn đừng vì ham JAV mà click link bậy bạ nhé,
3. Client XSS
Gầ àđ ,àkhiàJa a“ iptàdầ àđược sử dụng nhiềuàhơ ,à àlỗiàClie tàX““à ũ gà ị lợi dụng nhiều
hơ .àDoàJa a“ iptàđược sử dụ gàđể xử lýàDOM,à àđộ àđược chèn thẳng vào trong JavaScript.

Bản quyền thuộc về />
12


Bảo mật nhập mơn – Phạm Huy Hồng
Các lỗ hỗng dạng này khó tìm và phát hiệ à hơ à “e e à X““à hiều (Xem ví
dụ: />
Cách phịng tránh
Tơn chỉ củaàse iesà Bảo mật nhậpà
àl :àHa kàđể học, chứ đừng họ àđể hack. Mục tiêu của
mình khơng phảiàl àhướng dẫn các bạ àđiàha kà à uậy phá các site khác, mà là dạy bạn biết
và phòng chống nhữ gàđ àtấn cơng này.
Vì XSS là một dạng tấn cơng hay gặp, dễ gây hậu quả cao nên hầuà hưà àWe àF a e o kà
nổi tiế gà “p i g,àDja go,àá“P.NETàMVC àđều tích hợp sẵn cách phịng chống. Dù bạn là dân

ngoạiàđạo, khơng biết gì về XSS, chỉ cần sử dụng framework bản mới nhấtàl àđ àđề ph gàđược
kha khá lỗi rồi.

LỗiàX““à à ũ gàkh àdễ fix, quan trọng là lỗià àthường gặp ở nhiều trang, dễ s t,àdoàđ àsauà
khi fix ta phải verify cần thậ .àC à àphươ gàph pàthường dùng fix lỗi này:
1. Encoding
Kh gàđượ àti àtưởng bất kì thứ g à gười dùng nhập vào!! Hãy sử dụng hàm encode có sẵn
trong ngơn ngữ/framework để chuyển các kí tự < > thành < %gt;.

Bản quyền thuộc về />
13


Bảo mật nhập mơn – Phạm Huy Hồng
2. Validation/Sanitize
Một cách chống XSS khác là validation: loại bỏ hoàn toàn các kí tự khả nghi trong input của
gười dùng, hoặc thơng báo lỗi nếu trong input có các kí tự này.
Ngồi ra, nếu muố à hoàph pà gười dùng nhập vào HTML, hãy sử dụng các thưà iện sanitize.
C àthưà iện này sẽ lọc các thẻ HTML, CSS, JS nguy hiể àđể chống XSS. Người dùng vẫn có thể
sử dụng các thẻ

, <span>, <ul> để t hà à ă à ản.
L àơ ,à i à hắc lại,àl àơ àd gà àthưà iện sẵn có chứ đừ gà hổ o à iết lại để thể hiện
t hàđộ.àĐ à à ất nhiềuàt ường hợp dính lỗi XSS vì developer tự tin và tự viết code để loại bỏ
kí tự đặc biệtà …àđể sót.
3. CSP (Content Security Policy)
Hiện tại, ta có thể dùng chuẩn CSP để chống XSS. Với CSP, trình duyệt chỉ chạy JavaScript từ
nhữ gà do ai à được chỉ định. Giả sử thiendia.com có sử dụng CSP, chỉ chạy JavaScript có
nguồn gốc thiendia.com. V àKhoầđể
àđộc trên khoatran.com
àđoạn JavaScipt sau sẽ
kh gàđược thực thi.

Để sử dụng CSP, server chỉ cần thêm header Content-Security-Policy vào mỗi response. Nội
dung header chứa những do ai à àtầti àtưởng.

Lời kết
Nói hơià hủ ua àt à dồ
hàkồưầPHP ,àsố lượng trang web xây dựng bằng PHP bị lỗi XSS là
nhiều nhất. Lí do thứ nhất là do số lượng web viết bằng PHP cực nhiều. Lí do thứ hai là mặc
định PHP khơng encode các kí tự lạ. Các CMS củaàPHPà hưàWo dP ess,àJoo laà ất mạnh với
vô số plug-in. Tuy nhiên nhiều plug-in viết ẩu là nguyên nhân dẫ àđến lỗi bảo mật này.
Hiện tại, số lượng website bị lỗi XSS là khá nhiều, các bạn chỉ cần lang thang trên mạng là sẽ
gặp.àNhưà
hàđ à i,àX““àl à ột lỗi rấtà ơà ản, hầuà hưàha ke à oà ũ gà iết. Trang web bị
lỗi này rất dễ thành mồi ngon cho hacker. Do vậy, các bạn developer nhớ cẩn thậ ,àđừ gàđể
web của mình bị dính lỗi này.
Một số link tham khảo:



/> />
Bản quyền thuộc về />
14


Bảo mật nhập mơn – Phạm Huy Hồng

LƯU TRỮ COOKIE – TƯ NG KHÔNG H I AI
NG H I KHÔNG TƯ NG
Cookie là một khái niệm hết sứ à ơà ả à àtầđược học khi mới lập trình web. Tuy nhiên, nếu
sử dụ gàkh gàđ gà h,à àsẽ th hà ồià go à hoà àsố hacker. Bài viết này sẽ đề cập

đến những cách hacker mà có thể lợi dụ gà ookiềđể chiếm quyề à gười dùng, tấn cơng hệ
thống, cùng vớiàphươ gàph pàsử dụ gà ookieàđ gà hàđể gă à hặn những lỗ hổng này
nhé.

Cookie – Chiế à

hà ui àv àhại?

Server và client giao tiếp với nhau thông qua giao thức HTTP.àĐặ àđiểm của giao thức này là
stateless. Server khơng thể biếtàđược 2 request có tới từ cùng 1 client hay khơng. V àđặtàđiểm
,à ookiề ầđời. Về bản chất, cookie là một file text nhỏ được server gửi về lie t,àsauàđ à
o se à lưuà oà
à gười dùng. Khi client gửi request tới server, nó sẽ gửi kèm cookie.
Server dựầ ồ ookiề àđể nhậ à ầ gười dùng.
Cookiềthường có name, value, domain và expiration:





Na e,àđiàk à ới value: Tên cookie và giá trị củầ ookiềđ
Do ai :àDo ai à à ookieàđược gửiàl .àNhưàở h hàdưới, cookies chỉ được gửi khi
client truy cập wordpress.com.
Expiration: Thời gian cookie tồn tại ở máy client. Quá thời gian này, cookie sẽ bị xoá.

Bánh qui nho nhỏ,àđầy những lỗ to to
Sau khi tìm hiểuà ơà ản về cookie, ta sẽ tìm hiểu những lỗi bảo mật mà cookie có thể gây ra
nhé. Vì ookiềđược gửi kèm theo mỗi request lên server. Server dựầtheồ ookiềđể nhận
dạ gà gười dùng. Do vậy, nếu có thể h à ookie à ủầ gười khác, ta có thể mạo danh
gườiàđ .

Cookie có thể bị h

àtheồ

à o àđường sau:

Sniff cookie qua mạng: Sử dụng 1 số toolàđơ àgiả àđể s iffà hưàFiddle ,àWi esha k,àtầ àthể
chơm cookie củầ gười dùng ở cùng mạ g.à“auàđ , sử dụng EditThisCookie để dump cookie
này vào trình duyệtàđể mạồda hà gười dùng. (Xem demo phần HTTP).

Bản quyền thuộc về />
15


Bảo mật nhập mơn – Phạm Huy Hồng
Chơm cookie (Cookie thief) bằng XSS: Với lỗ hỗng XSS, hacker có thể chạ à àđộc (JavaScript)
ở ph ầ gười dùng. JS có thể đọc giá trị từ cookie với hàm document.cookie. Hacker có thể gửi
cookie này tới server của mình. Cookie này sẽ đượ àd gàđể mạoàda hà gười dùng.

Thực hiện tấn cơng kiểu CSRF (Cross-site request forgery). Hacker có thể post một link ảnh
hưàsau:
<img src=" />
Trình duyệt sẽ tự động load link trong ả h,àdĩà hi àl
àk àtheoà ookie.àĐường link trong
ảnh sẽ đọc cookie từ request, xác nhậ à gười dùng, rút sạch tiề à à gười dùng không hề
hay biết. Cách tấn cơng này có rất nhiều biến thể, mình sẽ nói rõ ở phần sau.

Cách phịng chống
Có thể áp dụng một số phươ gàph pàsau:





Set Expired và Max-Age:àĐể giảm thiểu thiệt hại khi cookie bị trộ ,àtaàkh gà
àđể
cookie sống quá lâu. Nên set thời gian sống của cookie trong khoảng 1 ngày tới 3
tháng, tuỳ theo yêu cầu của application.
Sử dụng Flag HTTP Only: Cookie có flag này sẽ khơng thể truy cập thơng qua
hàm document.cookie.àDồđ ,àd à e à à ị lỗi XSS thì hacker khơng thể đ hà ắpàđược
nó.
Sử dụng Flag Secure: Cookie có flag này chỉ được gửi qua giao thức HTTPS, hacker sẽ
khơng thể s iffàđược.

Vì cookie dễ bị tấn công, tuyệtàđối không chứa những thông tin quan trọng trong cookie (Mật
khẩu, số tài khoả ,à… .àNếu bắt buộc phảiàlưuàth à ần mã hoá cẩn thận.
Lưuàý: Nếu website của bạn sử dụng RESTful API, đừng sử dụng cookie để autho izeà gười
dùng mà hãy dùng OAuth hoặ àWe Toke .àToke à àđược vào Header của mỗi request nên
sẽ khơng bị dính lỗi CSRF.
Các bạn có thể tìm hiểu thêm về cookie và các lỗi bảo mật liên quan ở đ :






/> />admin.doc/concepts/csesmsession_mgmt.htm
/> /> />
Bản quyền thuộc về />
16

Bảo mật nhập mơn – Phạm Huy Hồng

SQL INJECTION – LỖ HỔNG B O MẬT THẦN
THÁNH
T o gà hươ gà , các bạn sẽ được tìm hiểu thự àhưà ề lỗ hổng bảo mậtà“QLàI je tio à thần
th h ,à ột trong những lỗ hổng bảo mật phổ biến và nguy hiểm nhất mọi thờiàđại.

Tại sao SQL Injection lạià thầ àth

h ?

Nhữ gàlýàdoàsauàđ àtạo nên tên tuổi lừng lẫy của SQL Injection:






Cực kỳ nguy hiểm – Có thể gây ra những thiệt hại khổng lồ. Với SQL Injection, hacker
có thể truy cập một phần hoặc toàn bộ dữ liệu trong hệ thống.
Rất phổ biến và dễ thực hiện – Lỗ hổng này rất nổi tiếng, từ de elope àđến hacker gần
hưàaià ũ gà iết. Ngồi ra, cịn có 1 số tool tấn cơng SQLàI je tio à hồd à goạiàđạo ,à
nhữ gà gười khơng biết gì về lập trình.
Rất nhiều ông lớn từng bị dính – Sony, Microsoft UK. Mọi vụ lùm xùm liên quan tớià lộ
dữ liệuà gườiàd g à tà hiềđều dính dáng tới SQL Injection.

Dễ tấn cơng, phổ biến, gây ra hậu quả nghiêm trọ g,àđ àl àlýàd àI je tà Kh gà hỉ SQL mà OS
và LDAP) nằm chễm chễ ở vị trí đầu bảng trong top 10 lỗ hỗng bảo mật của OWASP. Tất nhiên

là XSS, CSRF, và khơng mã hố dữ liệu ũ gà ằm trong list này nốt.

Hậu quả của SQL Injection
Hậu quả lớn nhất mà SQL Injection gây ra là: Làm lộ dữ liệu trong database. Tuỳ vào tầm quan
trọng của dữ liệu mà hậu quả daồđộng ở mức nhẹ hồđến vơ cùng nghiêm trọng. Nếu lộ dữ
liệu credit card, hacker có thể d gà edità a dàđể uầsắm hộ àhoặc chơm tiền củaà gười
dùng.
Hàng triệu Credit Card chùa tồn tại trên mạng, do hacker chôm từ các trang bán hàng thông
qua SQL Injection. Lộ dữ liệu khách hàng có thể ả hàhưởng rất nghiêm trọng đến cơng ty.
Hình ảnh cơng ty có thể bị ả hàhưởng, khách hàng chuyển qua sử dụng dịch vụ khác, dẫ àđến
phá sả à …
Lỗ hỗ gà à ũ gàả hàhưởng lớ àđến khách hàng. Do họ thường dùng chung một mật khẩu
cho nhiều tài khoản, chỉ cần lộ mật khẩu một tài khoản thì các tài khoả àkh à ũ gàlộ theo.
Đ à ũ gàl àlýàdồ
hà hắc nhở phải mã hố mật khẩu, nếu database có bị tấ à gàth à gười

Bản quyền thuộc về />
17


Bảo mật nhập mơn – Phạm Huy Hồng
d gà ũ gàkh gà ị mất mật khẩu.à Đ àl àlýàdoà ừa rồi vietnamwork bị ă à hửi vì khơng mã
hố mật khẩu).
Trong nhiềuàt ường hợp, hacker không chỉ đọ àđược dữ liệu mà cịn có thể chỉnh sửa dữ liệu.
Lúc này hacker có thể đă gà hậpàdưới vai trị admin, lợi dụng hệ thống, hoặc xố tồn bộ dữ
liệu để hệ thống ngừng hoạtàđộng.

Tấ à

gà“QLàI je tio à hưàthế nào?

Cơà hế “QLàI je tio à à gàđơ àgiả .àTaàthường sử dụng câu lệ hà“QLàđể truy cập dữ liệu.
Giả sử, muố àt àđă g nhậpàuse ,àtầthường viếtà odề hưàsau:

Đoạ à odềt àđọc thông tin nhập vào từ user và cộng chuỗiàđể thành câu lệnh SQL. Để thực
hiện tấn cơng, Hacker có thể tha àđổi thông tin nhập vào, từ đ tha àđổi câu lệnh SQL.

Hoặc nếu ghét, hacker có thể drop ln table Users, xố tồn bộ gười dùng trong database.
Đ gàsợ hưầ o?

Đến các mẹ bỉm sữa cịn biết cách dùng SQL Injection

Hacker có thể th gà uầ“QLàI je tio àđể dị tìm cấu trúc dữ liệu (Gồm những table nào, có
nhữ gà olu à g ,à sauà đ à ắtà đầu khai thác dữ liệu bằng cách sử dụng các câu lệnh
hư UNION,à“ELECTàTOPà …
Nhưà
hàđ à ià“QLàI je tio à ất phổ biến, bạn có thể dễ d gàgooglềđể tìm kiếm những
bài viết liên quan tới nó. Do vậy, mình chỉ tóm tắtàsơà ề ơà hế tấn cơng. Các bạn tự tìm hiểu
thêm qua các ví dụ ở bài viết này nhé: />
Cách phòng chống
May thay, mặc dù SQL rất nguy hạià hư gà ũ g dễ phòng chống. Gầ àđ ,àhầ hưà h gàtầ
ít viết SQL thuần mà tồn sử dụng ORM (Object-Relational Mapping) framework. Các
framework web này sẽ tự tạo câu lệnh SQL
àha ke à ũ gàkh àtấ à gàhơ .

Bản quyền thuộc về />
18


Bảo mật nhập mơn – Phạm Huy Hồng

Tuy nhiên, có rất nhiều site vẫn sử dụng SQL thuầ àđể truy cập dữ liệu.àĐ à h hàl à ồi ngon
hoàha ke .àĐể bảo vệ bả àth àt ước SQL Injection, ta có thể thực hiện các biện pháp sau.







Lọc dữ liệu từ gười dùng: Cách phòng chố gà àtươ gàtự hư XSS. Ta sử dụng filter
để lọc các kí tự đặc biệtà ;à à àhoặc các từ kho à “ELECT,àUNION àdoà gười dùng nhập
vào. Nên sử dụ gàthưà iện/function được cung cấp bởi framework. Viết lại từ đầu vừa
tốn thời gian vừa dễ sơàs t.
Không cộng chuỗià để tạo SQL: Sử dụng parameter thay vì cộng chuỗi. Nếu dữ liệu
truyền vào không hợp pháp, SQL Engine sẽ tự động báo lỗi, ta không cần dùng code
để check.
Không hiển thị exception, message lỗi: Hacker dựa vào message lỗiàđể tìm ra cấu trúc
database. Khi có lỗi, ta chỉ hiện thơng báo lỗi chứ đừng hiển thị đầ àđủ thông tin về
lỗi, tránh hacker lợi dụng.
Phân quyền rõ ràng trong DB: Nếu chỉ truy cập dữ liệu từ một số bảng, hãy tạo một
account trong DB, gán quyền truy cậpà hoàa ou tàđ à hứ đừng dùng account root
hay sa. Lúc
,àd àha ke à ài je tàđượ às là ũ gàkh gàthể đọc dữ liệu từ các bảng
chính, sửa hay xố dữ liệu.
Backup dữ liệuàthường xuyên: Các cụ à uà ẩn tắ à à à
.àDữ liệu phảiàthường
u àđượ à a kupàđể nếu có bị hacker xố thì ta vẫn có thể khơi phụ àđược. Còn nếu
cả dữ liệuà a kupà ũ gà ị o àlu àth à…à h à ừng bạn, update CV rồi tìm cách chuyển
cơng ty thơi!

Kết luận
Dữ liệu là một trong những thứ đ gàtiề à hất trong website của bạ .à“auàkhiàđọc xong
hươ g này, hãy kiếm tra lại xem trang của mình có thể bị tấn cơng SQL Injection hay không,
sauàđ à pàdụng nhữ gàphươ gàph pà
hàđ àhướng dẫ àđể fix.
Nguồn tham khảo thêm





/> /> /> />
Bản quyền thuộc về />
19


Bảo mật nhập mơn – Phạm Huy Hồng

INSECURE DIRECT OBJECT REFERENCES –
GI U ĐẦU LỊI ĐI
Ở hươ gà , mình sẽ giới thiệu một lỗ hổng bảo mậtàkh à lạ à a gà iàt
kh àđọc: Insecure Direct Object References.

àd iàloằng ngoằng

Lỗi gì mà tên dài rứa??
Lỗià à lạ àở chỗ nó nằm trong top 4 OWá“Pà hư gàlại có rất ít tài liệu về .àN à ũ gàkh gà
nổi tiế gà hư XSS hay CSRF hay SQL Injection (Dù rank OWASP củầ à aồhơ àX““àha àC“‘Fà
nhiều). Bả àth à
hàt ướ àđ à ũ gà hưầhề nghe báo chí hay tin tức gì nhắc tới lỗi này. Có

thể l àdồ hưầ vụ án nổi tiế gà ồli à ua àđến nó, hoặc do lỗi này có nhiều biến thể phức
tạpà hă g?
Nguyên nhân chính gây ra lỗ hổng này là sự bất cẩn của developer hoặc sysadmin (Gặp lỗi này
là phải lơi thằ gàde à ầ h àt ướ ,àsađ à h àteste . Lỗ hổng này xảy aàkhià hươ gàt hà
hoàph pà gười dùng truy cập tài nguyên (dữ liệu,àfile,àthưà ục, database) một cách bất hợp
pháp, thơng qua dữ liệdồ gười dùng cung cấp.àĐể dễ hiểuàhơ ,àh àđọc ví dụ ph ầdưới
nhé.

Cách lợi dụng lỗ hổng
Rất tình cờ, mình phát hiện lỗià
àkhiàđa gàgi pà ột thằ gàe àtestàđồ án web bán hàng.
Trong mụ à Quả à lýà đơ à h g ,à U‘Là ủa mộtà đơ à h gà sẽ có dạ gà hưà
sau: Server sẽ đọc ID 1230 từ U‘L,àsauàđ t àđơ àh gà à
ID 1230 trong database và đổ dữ liệu vào HTML.
Bắtà hướ àha ke ,à
hà ghịch ngợ à ột tí, thay 1230 bằng các giá trị từ 1 tới 2000. Hệ
thống cứ thế àđọc và hiển thị cho mình tồn bộ
àđơ àh gà àIDàtừ 1 tới 2000 (kể cả đơ à
hàng của các khách hàng khác). Tai hạià hưa!

Bản quyền thuộc về />
20


Bảo mật nhập mơn – Phạm Huy Hồng
Lỗ hổng ở đ à h h l :à hươ gàt hà hoàph pà
hàt u à ậpàt ià gu à đơ àh gà ủầ gười
khác) bất hợp pháp, thơng qua dữ liệu (ID) mà mình cung cấp qua URL. Lẽ a,à hươ gàt hà
phải check xem mình có quyền truy cập các dữ liệu này hay khơng.
Trong thực tế, hacker có thể dùng nhiềuà hi uàt à hư:àtha àđổiàU‘L,àtha àđổi param trong

API, sử dụ gà toolà để scan nhữ gà t ià gu à kh gà được bảo mật. Chiêu hack lotte
cinema g à ưaà ủaà
hà ũ gà aà à hưà thế, thay id trong URL bằng username trong
cookie.
C hàđ àkhoảng 1-2 tháng, có 1 vụ lùm xùm liên quan tớià gàt àXà H hà hưàl àCGV ,àlộ tài
khoản của 3 triệuà gười dùng. Chính lỗ hổng Insecure Direct Object References
àđ àgi pà
hacker (ở đ àl àth hà ảo mật Juno_okyo) lợi dụng và dị ra thơng tin của 3 triệ gười dùng
đ .

(Bài viết gốc khá hay ở đ : />Có một vài vụ việc hi hữu, hacker s a àđược git repository nằm trên server. Truy cập git, hắn
lấ àđược username, password của database và các thông tin quan trọng khác. Bạ àđừ gà ghĩà
l à
h…à hưà ấu.à C hà đ à ià h , git của vietnamwork vẫn nằm public chễm chệ tại
vietnamwork.com/.git/, khơng bảo mật gì! May mà gặpàha ke à àt
àđià ga gà uaà
à
hưaà àg àđ gàtiếc xảy ra.

Bản quyền thuộc về />
21


Bảo mật nhập mơn – Phạm Huy Hồng

Cách phịng chống
Một số biện pháp phòng chống:
Test cẩn thận – Nguyên nhân gây ra lỗiàthường là do sự bất cẩn của developer. Tuy nhiên, nếu
để sản phẩm bị lỗiàth àđ àl àlỗi củầteste .àĐ y là lỗi nằ àt o gà ode,àdồđ àteste àphải chịu
trách nhiệm nếuàđể lỗi này xả àđến vớià gười dùng.

Bảo vệ dữ liệuà hảy cả – Với những dữ liệuà hạy cả à hưàsou eà ode,à o fig,àdata aseà
key, cần hạn chế truy cập. Cách tốt nhất là chỉ cho phép các IP nội bộ truy cập các dữ liệu này,
hacker khỏi táy máy.
Kiểm tra chặt chẽ quyền truy cập của user – Hãy thử xem tiki giải quyết vấ àđề
à hưàthế
o?àĐơ àh gàt àtiki. à àdạng: />
Dễ thấ ,àtikiàđể id củaàđơ àhàng trong URL. tuy nhiên, khi mình thử tha àđối id củầđơ àh gà
thì tiki redirect mình lại trang Bảo mật có tâm là phảià hưà
thế!
T hàđể lộ key củaàđốiàtượng – T o gà àt ường hợpàđ à u,àidà ủaàđốiàtượng là số int, do
đ àha ke à àthể đo à aàidà ủaà àđốiàtượng khác. Nhằm phịng tránh việt này, ta có thể mã
ho àid,àd gàGUIDàđể làm id. Hacker khơng thể nào dị ra ID củầđốiàtượ gàkh àđược.

Lotte Cinema giờ đ à

àho àuse

a eàt o gà ookie,àkh ỏi nghịch ngợm nhé

Một số nguồn tham khảo thêm:





/> /> />
Bản quyền thuộc về />
22

Bảo mật nhập mơn – Phạm Huy Hồng

CSRF – NHỮNG CÚ LỪA NGO N M C
Trong Tam Quốc, các bậ à u àsưàt ià ă gà àt iàđiều binh khiể àtưởng, ngồiàt o gàt ướng
bồng quyết thắ gà hàđ àh gà g àdặm. Trong Tu Chân, các cao thủ à hi uà C hàKh gà
Thủ Vật àđiều khiể àđồ vật từ xa, hoặ à Ngự Kiế àPhiàH h ,àd gà h àkh àđể điềuàđộng phi
kiếm hay pháp bảo.
Ngày nay, hacker ũ gà à hi uàthứ àtươ gàtự gọi là CRSF. Hacker có thể ngồi tại website
A mà dụ dỗ gười dùng tấn công site B và site C khác. Chươ gànày sẽ giải thích cách hacker
tấ à g,àđồng thờiàhướng dẫn cách phịng chống cho các bạn lập trình viên nhé.

Cơà ản về CSRF
C“‘Fà àt àđầ àđủ là Cross Site Request Forgery (Tên khác là XSRF). Lỗ hổng này khá phổ
biến, Netflix và Youtube ũ gàtừng là nạn nhân của lỗ hổng nó. Hậu quả dồ àg à ầ ũ gà
hơi à ghi àt ọng nên CRSF hân hạ hàđược nằm trong top 10 lỗ hổng bảo mật của OWASP.
Nguyên tắc hoạtàđộng của CRSF rấtàđơ àgiản. Ở iàt ước, chúng ta biết rằng server sẽ lưuàt ữ
cookie ở ph aà gườiàd gàđể phân biệtà gười dùng. Mỗiàkhià gười dùng gửi một request tới
một domain nàoàđ , cookie sẽ được gửi kèm theo.









Đầuàti ,à gười dùng phảiàđă gà hập vào trang mình cần (Tạm gọi là trang A).
Để dụ dỗ gười dùng, hacker sẽ tạo ra mộtàt a gà e àđộc.
Khià gười dùng truy cậpà oà e àđộc này, một request sẽ được gửiàđến trang A mà

hacker muốn tấ à gà th gà uầfo ,ài g,à… .
Dồt o gà e uestà à àđ hàk à ookiề ủầ gườiàd g,àt a gà e àáàđ hàsẽ nhầm
rằ gàđ àl à e uestàdoà gười dùng thực hiện.
Hacker có thể mạồda hà gườiàd gàđể l à àh hàđộ gà hưàđổi mật khẩu, chuyển
tiề ,à….

Để dễ hiểuàhơ ,à ạ àh àđọc phần ví dụ ph ầdưới nhé.

Các kiểu tấ à

gàthường gặp

Kiểu 1. Dùng form
Ngày xửaà g à ưa,à àhaiàa hàe à h à ọ t àl àTư gà àTườ .àTư g,à gườiàa h,à hă àloàhọc
h h,à h àth àl àă à u ià ợ o .àNgườiàe ,àTườ àth à gười lại, suốtà g àl àthi àđịa share
h gà àt àđịaàđiểm mát xa.

Bản quyền thuộc về />
23


Bảo mật nhập mơn – Phạm Huy Hồng
Một hơm nọ, cãi nhau với vợ,àTư gà uồn quá muốn bỏ đià tà a.àTiếc thay, lên thiendia hỏi
địa chỉ kh gàaià hoà àTư gàt àdụng quá thấp. BiếtàTườn là thành viên cộ à ,àTư gà
à
ă à ỉ Tườn cho mượ àa à hư gà àsợ a hàhưàhỏ gà
àTườ àkh gà ho.àĐ gàl àa hàe à
tốt!! Phẫ à h ,àTư gà u ếtàđịnh dùng lỗiàC“‘Fàđể chơm account củầTườn.
Ta hãy quan sát HTML củầ fo à đổi mật khẩuà thi à địa. Form này gồm 2 field
là password và password_confirm, submit tới http://thi*ndia.com/account/security-save

Tư gàl àgiả một trang web JAV, giả vờ gửi cho thằng em xấu số. Trong trang web có một
form ẩn với các giá trị tươ gàtự fo àt à C àđồ gàd* à uiàl gàđể ý form HTML bên trái và
button bên phải).

Thanh niên Tườ à g àthơà àIT,àlỡ tay vào link và bấm vào button. Mộtà e uestàđổi password
được gửiàđến thiendia, kèm theo cookie account củaàTườn. Thế l à o g!àTư gà hỉ cần dùng
email + mật khẩu mớiàl à
àđể đă gà hập vào account của thằng em xấu số.
Kiểu 2. Dùng thẻ img
Chuyện tớiàđ à hưaàhết.àC àđịaàđiể à tà a,à hư gàtiền bạc do vợ nắm cả,àTư gàkh gà à
tiề à đià tà a.à Tư gà u ếtà định hack ln tài khoản ngân hàng củầ Tườn. Tườn sử dụng
JAVBank (Japan America Vietnam Bank).
Mỗi lần chuyển khoản, ngân hàng sẽ tạo 1 URL. Giả sử gười A muốn chuyể à
à hồ gười
B,àu làđược tạo ra sẽ có dạng k?from=Person1&to=Person2&amount=1000.

Bản quyền thuộc về />
24