Bao mat nhap mon

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àtaàđ gà aiàha ke àđể tấn công hệ thống mình viết.àTh gà uaàđ ,à 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. Đaà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ủaà h hàde elope .àDoàđ ,àh àđọc kĩàe ook và cố gắng áp dụng những kiến thứ à à oà odeàđể tránh dính các lỗi này nhé. Đ àl àse ieshướ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ừaàđảoà 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.

M c l 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ẤUàĐẦUàLÒIàĐUÔ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ấn c gàthường gặp ... 23

Lưuàý ... 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àtaàđể 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ế oà hoàđ 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

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

LOóI.VNàĐÃà VÔàÝ àĐỂ LỘ DỮ LIỆU 2 TRIỆUà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

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 àgiaoàthức HTTP.

Đươ gà hi ,àhoaàđẹ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à Hoàng cờ hó.

Search Linh phát nó ra con bé Linh lộ lipà +àlu ….

Thằng Hoà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ưà oà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ửaàđổi packet

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ềuà 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ạng 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ã hoá à gười ngoài không thểđọc trộm hay chỉnh sửaàđượ .àC hà àtươ gàtự hưà iệc bạn và Linh viết mail cho nhau bằng teencode, thằng Hoàng cờh àkiaà àđọc trộ à ailà ũ gàkh gàhiểu hay sửaàthưàđược.

Tu àđộ bảo mật của HTTPS vẫ à hưa phải là tuyệtàđối, nó vẫ à aoàhơ à hiều so với chỉ dùng HTTP thuần. Ngoài ra, nếu trang web của bạ à hưaà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

Lưuàý

Hiện tại nhiều trang web vẫn sử dụ gà httpsàgiả cầ à– chỉ sử dụng https ở những trang log-in 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ạ .àDoàđ ,à ầ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.

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ụ gà ookieà àđểđă gà hậpà hưàthường.

Dùng Fiddler đọc lén cookie

D gàEditThisCookieàđể du pà ookieà àđă gà hậpà hưàthườ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ửaàpa ketàđể dẫ à gười dùng tới trang lừaàđảo.

Đườ gàli kàđ à ị đ hàt oà à 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 toà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!

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à ,àX““à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ủaàse e àXà oàđ .

"Ờthì ghe cũ g c vẻ nguy hiể đấ , hư g sao t i thấy ông hay viết về XSS thế? Rảnh quá hả!?"

À... 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à odeà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ố àt àJáV ,àse e àsẽlưuàlại và hiển thị

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ạ àđ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““àđ uà h , các bạn không nên thử).

Trong kiểu tấ à gà ,à àđộc đựợ àlưuàt o gàdata aseàt àse e ,àhiển thị ra với toàn bộ gười dùng,àdoàđ àtaàgọi nó là Persistance XSS. Bất kì ai thấy comment củaàKhoaàđều bị dính

àđộ à ,àdoàđ à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 h à àđộ à 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ẽ vào trang thiendia. Sauàđ à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

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ụ: http://kipalog.com/posts/To-da-hack-trang-SinhVienIT-net-nhu-the-nao).

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

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.

Ngoà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ố gàX““.àNgười dùng vẫn có thể sử dụng các thẻ <p>, <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à odeàđể 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 àKhoaàđể àđộ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 à àtaàti àtưởng.

L

ờ

i k

ế

t

N iàhơià hủ ua àt à doà hàkoàưaà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:

 http://excess-xss.com/

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ứ à ơà ả à àtaàđượ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à ookieàđể 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 ,à ookieà aàđờ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ựaà oà ookieà àđể nhậ à aà gười dùng.

Cookieàthường có name, value, domain và expiration:

 Na e,àđiàk à ới value: Tên cookie và giá trị củaà ookieàđ

 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ì ookieàđược gửi kèm theo mỗi request lên server. Server dựaàtheoà ookieàđể nhận dạ gà gười dùng. Do vậy, nếu có thể h à ookie à ủaà gười khác, ta có thể mạo danh

gườiàđ .

Cookie có thể bị h àtheoà à o àđường sau:

Chôm cookie (Cookie thief) bằng XSS: Với lỗ hỗng XSS, hacker có thể chạ à àđộc (JavaScript) ởph aà 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:

<imgsrc="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

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.àDoàđ ,à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 ởđ :

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. Ngoài ra, còn có 1 số tool tấ à gà“QLàI je tio à hoà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àđề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ã hoá 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ảdaoàđộng ở mức nhẹ hoàđến vô cùng nghiêm trọng. Nếu lộ dữ liệu credit card, hacker có thểd gà edità a dàđể uaà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ả à …

d gà ũ g không bị mất mật khẩu.à Đ àl àlýàdoà ừa rồi vietnamwork bịă à hửi vì không mã hoá 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 xoá toà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à hậpàuse ,àtaàthường viếtà odeà hưàsau:

Đoạn codeà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 luôn table Users, xoá toàn bộ gười dùng trong database. Đ gàsợ hưaà o?

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

Hacker có thểth gà uaà“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àgoogleàđể 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é: http://expressmagazine.net/development/1512/tan-cong-kieu-sql-injection-va-cac-phong-chong-trong-aspnet.

Cách phòng ch

ố

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 ha àsa.àL à ,à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 xoá 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 xoá thì ta vẫn có thể khôi phụ àđược. Còn nếu cả dữ liệuà a kupà ũ gà ị xoá luôn 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

INSECURE DIRECT OBJECT REFERENCES

–

GI

U ĐẦU LÒI ĐUÔ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 àd iàloằng ngoằng kh àđọc: Insecure Direct Object References.

L

ỗ

i gì mà tên dài r

ứ

a??

Lỗià à lạ àở chỗ nó nằ àt o gàtopà à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à à aoàhơ àX““àha àC“‘Fà nhiều). Bả àth à hàt ướ àđ à ũ gà hưaàhề nghe báo chí hay tin tức gì nhắc tới lỗi này. Có thểl àdoà hưaà à ụ án nổi tiế gà oà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ằng dev ra ch àt ướ ,àsauàđ à h àteste . Lỗ hổng này xả à 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ệuàdoà gười dùng cung cấp.àĐể dễ hiểuàhơ ,àh àđọc ví dụ ph aà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: http://shop.com/user/order/1230. Server sẽđọc ID 1230 từU‘L,àsauàđ t àđơ àh gà à ID 1230 trong database và đổ dữ liệu vào HTML.

Lỗ hổng ởđ à h hàl :à hươ gàt hà hoàph pà hàt u à ậpàt ià gu à đơ àh gà ủaà 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ệuà gười dùng đ .

(Bài viết gốc khá hay ởđ : https://junookyo.blogspot.com/2016/10/ro-ri-3-trieu-thong-tin-ca-nhan.html).

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à à

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ủaàteste .àĐ àl àlỗi nằ àt o gà ode,àdoàđ à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: https://tiki.vn/sales/order/view?code=33598178

Dễ thấ ,àtikiàđể id củaàđơ àh gàt o gàU‘L.àtu à hi ,àkhià hàthửtha àđối id củaàđơ àh gà thì tiki redirect mình lại trang https://tiki.vn/sales/order/history. Bảo mật có tâm là phảià hưà thế!

T hàđể lộ key củaàđốiàtượng – Trong à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ủaàđốiàtượ gàkh àđược.

Lotte Cinema giờ đ à àhoá username trong cookie, khỏi nghịch ngợm nhé

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

 https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References

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ông 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ảdoà àg à aà ũ 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 ngườ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àdo ai à 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à uaàfo ,ài g,à… .

 Doàt o gà e uestà à àđ hàk à ookieà ủaà 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ạoà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 aàdưới nhé.

Các ki

ể

u t

ấ à

gàthườ

ng g

ặ

p

Kiểu 1. Dùng form

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ông ai cho àTư gàt àdụng quá thấp. BiếtàTườn là thành viên cộ à ,àTư gà à ă à ỉTườ à hoà ượ à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ủaàTườn.

Ta hãy quan sát HTML củaà 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ự form t à C àđồ gàd* à uiàl gàđể ý form HTML bên trái và button bên phải).

Tha hà i à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 luôn tài khoản ngân hàng củaà Tườn. Tườn sử dụng JAVBank (Japan America Vietnam Bank).

Tư gà ỏ url này vào 1 thẻi g.àKhiàTườn truy cập trang, trình duyệt sẽ tự gọi GET request, gắn kèm với cookie trên JAVBank củaàTường. Thông qua cookie, ngân hàng xác nhậ àđ àl àTườn, chuyển tiề à uaà hoàTư g.

Có tiền lạià àđịaàđiể ,àTư gàdối vợ l àđường mát xa. Chuyện về sau có nội dung 18+ nên mình không kể nữa….

Lưuàý

Tất nhiên, trong bài chỉ là ví dụ. Theo nguyên tắc, request GET chỉđược dùng để truy cập dữ liệu,àkh gàđượ àd gàđể thực hiện các hoạtàđộng thay đổi dữ liệuà hưàedit/delete. Các ngân h gàthường bảo mật rấtàkĩà ằng cách set cookie có thời gian sống khá ngắn, không cho phép chuyển tiề à àkh gà à odeàOTPà … .

Ngoài ra, thi* diaà ũ gà à à iện pháp bảo mật khá tốtà e àph aàdưới) nên các bạn không d gà hà àđể chôm account của bạ à àđượ àđ u,àđừng thử nhé!

Ảnh minh hoạ từ thi àđịa, trang này có CSRF token

Phòng ch

ố

ng cho website

Dướiàđ àl à ột số cách phòng chố gàC“‘Fà ơà ản:

 Sử dụng CSRF Token: Trong mỗiàfo àha à e uest,àtaàđ hàk à ột CSRF token. Token àđược tạo ra dựa theo session của user. Khi gửi về server, ta kiể àt aàđộ xác thực củaà sessio à .à Doà toke à à được tạo ngẫu nhiên dựa theo session nên hacker không thể làm giảđượ à C àf a e o kà hưà‘o‘,àCodeIg ite ,àá“P.NETàMVCàđều hỗ trợ CSRF token).

 Kiểm tra giá trị Referer và Origin trong header: Origin cho ta biết trang web gọi request này. Giá trị àđượ àđ hàk àt o gà ỗi request, hacker không chỉnh sửa được. Kiểm tra giá trị này, nếu nó là trang lạ thì không xử lý request.

 Kiểm tra header X-Requested-With: Request chứa header này là request an toàn, vì heade à à gă àkh gà hoàtaàgửià e uestàđến domain khác (chi tiết).

 Cần cẩn thậ àđề phòng lỗi XSS: Với XSS, hacker có thể ià àđộc trên chính trang web cần tấn công. Lúc này, mọià phươ gà ph pà ph ng chống CSRF hưà toke ,à referrer đều bị vô hiệu hoá. Bản thân bác juno_okyo từng áp dụng lỗi CSS kết hợp C“‘Fàđể tấn công sinhvienit.net (Chi tiết).

T

ổ

ng k

ế

t

Ng àt ước lỗi này khá nghiêm trọng và phổ biến. Gầ àđ à àf a e o kàhầuà hưàđều mặc định chống lỗi này nên tần suất gặpà ũ gà tàđi.àTu à ậy ta vẫn phảiàđề phòng, nhất là các website tự odeà h à Đặc biệt là code bằng PHP, ahihi).

Ngoài ra, là một user, bạn cần biết tự bảo vệ mình theo nhiều cách sau:

 Đă gà uất khỏi account sau khi sử dụ gàđể tránh lưuà ookie.

 Không click quảng cáo hay button lung tung.

 Kh gàgh àthă à àt a gà ậy bạ, nguy hiể .àNhưàđ à iàph aàt ,à hiều khi ta không bấm nút gì, chỉ cần truy cập trang, trình duyệtà ũ gà tự động post dựa trên javascript hoặc thẻ img. (Nếu bắt buộc, hãy sử dụng chế độ ẩn danh trong Chrome).

Nguồ àđể tham khảo thêm:

 https://en.wikipedia.org/wiki/Cross-site_request_forgery

 https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

 http://stackoverflow.com/questions/17478731/whats-the-point-of-the-x-requested-with-header

Ẩ

N GI U THÔNG TIN H

Ệ

TH

Ố

NG

–

TRÁNH

CON M

ẮT NGƯ I Đ

I VÀ K

Ẻ

X U

Chươ gà àđề cập tới mộtàphươ gàph p bảo mật à gàđơn giản, hiệu quả hư gàlạiàđược tà gười biết và áp dụ g.àĐ àl àphươ gàph p:àGiấu thông tin hệ thống.

Thông tin h

ệ

th

ố

ng là gì?

Có thể tạm hiểu thông tin hệ thống là những thông tin về cấu tạo và hoạtà động của hệ thống đ . Lấy lottecinema ra làm ví dụ: Thông tin về hoạtàđộng là file log, error page hiển thị khi bị lỗi. Thông tin về cấu tạo củaàt a gà à hưàsauà L àdoàl àsaoà hà iếtàđược thì các bạn theo dõi phần sau):

 Trang chính sử dụng KenticoCMS. Phiên bản sử dụng là ASP.NET WebForm 2.0

 Theo dựđo àthì do dùng ASP.NET nên database sẽ là MS SQL Server

 Trang web có sử dụng jQuery và jQueryUI

 T a gà e àđược deploy trên Server ISS7

Chắc bạ àđa gàtự hỏi: Ủa, nếu hệ thống của mình không làm gì mờ ám thì sao phải giấu? Ừ nhỉ!àH àtưở gàtượng nhà bạn là tiệm vàng có rất nhiều tiền và vàng bạc. Liệu bạn có treo biể à G àdưới hàng rào có lỗ hổng, két sắtà h àtaoàđểở lầu 3, két hiệu Việt Tiến, mật khẩu 4 chữ số àkh g?

Dĩà hi ,à ạn không bao giờđể thông tin nhà cửa hớh hà hoàă àt ộm biết.àĐiều này giống như mời trộm vào nhà vậy. Tu à hi ,àđaàphần chúng ta lạiàđể hớh h àth gàti àhệ thống cho hacker thấy. Thế có khác gì mời hacker tấn công kh gà ơà hứ!!

Chú gàtaàđể

thông tin h

ệ

th

ố gà hớ

hê h à hưàthế

nào?

Ch gàtaàthườ gàđể lộ thông tin hệ thống một cách rấtà hớ h h ,àkh gàthuaàg à hàe à Linh Miu khoe thân trong mấy bộ đồ thiếu vảià Điển hình là vụ lộ vếu nổiàđ hà ổiàđ àgần đ .àDướiàđ àl à ột số kiểu lộth gàti àthường gặp:

Hiển thị chình ình trên trang sợ gười khác không nhìn thấy

Hiển thị rõ phiên bản .NET, Exception khi bị lỗi.àĐ àl à ồi ngon cho tấn công SQL Injection

Để trong header trả về từ server

Tất cả nhữ gàth gàti à àđều có thể dễ dàng truy ra bằng buildwith.com. Trang này hoạt độ gàt à gu àlýàđọc các header trả về từ server, xem HTML include các thưà iện nào.

Nh

ữ

ng h

ậ

u qu

ả

c

ủ

a vi

ệ à lộ

h g

Nhữ gàth gàti à àhại à à ũ gà àt hà gi pàđỡ àha ke àtấn công hệ thống của bạn dễ d gàhơ à ằng những cách sau:

 Biếtà được phiên bản thưà iện/framework sử dụng, phiên bản server, phiên bản database, …àha ke à àthể tìm ra lỗ hổng bảo mật (CVE) của hệ thống. Việc tra cứu rất dễ dàng, chỉ cần vào nvd.nist.gov. Dựa theo phiên bản framework/server/database, hacker có thể thấ àđược những lỗ hổng bảo mật của các phiên bản này. Từ các lỗ hổng này, hacker có thể tìm cách tấn công hệ thống.

 Ngoài ra, khi biếtàđượ àf a e o kàđa gàsử dụng, hacker có thể à aàđường dẫn tới trang admin (Với wordpress là /wp-admin, với joomla là /administrator, với phpmyadmin là /phpmyadmin). Tiếp theo, hacker có thể thử nhập username/password admin mặ àđị hàđểđă gà hập vào hệ thố g.àĐ gàsợ hưa??

 Với mobile app hoặc phần mềm, hacker có thểde o pileàđể chôm API hoặc security key. Chẳng giấu gì các bạ ,à hà ũ gàtừng decompile file API củaà“i si iàđể lấy Key và API miễn phí gắn vào chat bot facebook ấ …

Gi

ấuà hưàthế

oà hoàđú g?

Cảnh giới cao nhất của việc giấu hàng là hacker không thể biết được hệ thống của bạ àđược viết ngôn ngữ/framework gì, dùng database gì, deploy ở đ u.àĐiều này làm công việc của hacker trở àkh àkhă àhơ à ất nhiều. Thật ra, việc giấu thông tin hệ thố gà ũ g không quá kh àkhă àha à ất thời gian. Chỉ cần bạ àđể ý và cẩn trọ gàl àđược.

Một sốphươ gàph pà giấuàth gàti àha àd g:

 Config server hoặc viếtà odeàđể loại bỏ nhữ gàHTTPàheade àdưàthừa.

 Khi deploy, ta obfustace hoặc uglify code để code trở à kh à đọ .à Để tránh việc hacker biếtà àthưà iện JS sử dụng thì ta có thể bundle toàn bộthưà iện và code thành 1 file luôn.

 Khi hệ thống bị thống, hiển thị custom Error Page. Lỗi trong trang này nên giải thích rõ gà hoà gười dùng hiểu.à Như g tuyệtà đối không hiển thị trực tiếp error/exception để tránh hacker tấn công.

QU

N LÝ NGƯ

I DÙNG

–

TƯ

NG D

Ễ

ĂN MÀ

KHÔNG ĐƠN GI

N

We siteàđược tạoà aàl àđể phục vụ gười dùng. Có gười sử dụng thì website và doanh nghiệp mới có thu nhập. Một trong những việc rắc rối nhất chính là quản lý và bảo mật thông tin

gười dùng.

Trong bài này, mình chia sẻ nhữ gàđiều cầ àlưuàýàkhiàthực hiệ àt hà ă gà .àKh à hiều khê và phức tạpàđấy, các bạn chịuàkh àđọ àkĩà h !

Úi gi

ời!àĐă gàkíàđă gà hậ

p có gì khó?

Kh gà hưà ạ àtưở gàtượng, việ àđă gàk /đă gà hập và quả àlýà gười dùng thật ra không hề đơ àgiản. Nó có thể trở nên khá loằng ngoằng với nhữ gàt hà ă gàsau:

 Choàph pà gườiàd gàđă gàk ,àđă gànhập bằng email

 Phân quyề à gười dùng

 Tích hợp với Gmail, Facebook

 Tích hợp với hệ thố gà gười dùng có sẵn trong doanh nghiệp

 Reset mật khẩuàkhià gười dùng quên

 Blo kàa ou tàkhià gười dùng nhập sai pass nhiều lần

 Bảo mật cho API vớiàappàdiàđộng

 Bảo mật 2 lớp (Two factor authentication) với các account quan trọng

 Quản lý: Thêm bớt xoá sửaà gười dùng

Khiàt hà ă gà àhoạtàđộng ổ àđịnh, không ai khen nó lấy một câu. Tuy nhiên, chỉ cần nó gặp phải chút vấ àđề,à a àđoa à ạn sẽ hứng chịu vô số ơ àthịnh nộ từ khách hàng.

Quan tr

ọ

ng nh

ấ

t

–

Kh gàlưuà ậ

t kh

ẩ

u!

Đến cả web lớ àl à iet a o kà à ũ gàtắ àt hàđến mức không dùng https khiàđă gà hập, không bảo mật dữ liệuà đến nỗi làm lộ mật khẩu củaà gười dùng: http://nghenhinvietnam.vn/tin-tuc/web-tim-viec-vietnamwork-bi-tan-cong-23535.html. Hậu quả của việ à à ũ gàkh gà àg à ghi àt ọng, cùng lắm là mất mặt công ty, mất account khách hàng và làm khách hàng chuyển qua dùng dịch vụ khác thôi.

Làm th

ế

oàkhià gườ

i dùng quên m

ậ

t kh

ẩ

u?

Doàkh gàlưuà ật khẩu trong database, ta không thể gửi mật khẩu về ailà hoà gười dùng khi họ quên mật khẩu. Ởđ àtaà à à hàgiải quyết.

Cách 1: Reset mật khẩu mới ngẫu nhiên rồi gửià hoà gười dùng

Cách này có thể làm lộ mật khẩu vì email có thể bịđọc trộm. Ngoài ra, nếuà hưà iếtàđịa chỉ mail, hacker có thể lợi dụ gà àđể reset mật khẩu hàng loạtà gười dùng, nhằ à gă à ản họ đă gà hập vào hệ thống.

Cách 2: Gửiàli kàđể gười dùng reset

Dựa theo tài khoản, ta tạo reset token rồi gắn nó vào link: http://shop.com/resetpass?token=32343, gửiàli kà à oà ailà hoà gười dùng.

Người dùng sử dụ gàli kà àđể reset mật khẩu. Với cách này, dù hacker có request reset thì mật khẩuà gười dùng vẫn giữ nguyên, không bịả hàhưởng. Nhưàđ à iàph aàt ,àdoàe ailà kh gàa àto à àtoke à à àđược expired ngay sau khi dùng, hoặc sau 24-48 tiế gàđồng hồsauàkhiàe ailàđược gửiàđi.

Gửi email có link Reset Password về choà gười dùng

Ch

ố

ng vi

ệ àđo à

à ậ

t kh

ẩ

u

Để dò mật khẩu, hacker có thể viết một con bot, lầ àlượt submit username và password cho tớiàkhiàđă gà hậpàđượ .àĐể phòng tránh việc này, ta áp dụng nhữ gàphươ gàph pàsau:

 Khià gườiàd gàđă gà hậpàsai,àđừng báo là sai username hay sai password. Chỉ cần báo username hay password không match, hacker sẽ gặpàkh àkhă àhơ .

 Hạn chế số lầ àđă gà hập khi nhập mật khẩu sai. Ví dụ sau 3 lần nhập pass sai thì khoá account trong 10 phút. Hacker có thểd gà hà àđể khoá tài khoả à gười dùng, nên cẩn thận. Có thể kết hợp thêm capcha.

Lưuàý:àNhững cách cách này có thể gây khó chịuà hoà gười dùng, nếu dữ liệu không quá quan trọng (game, web hỏiàđ p,àgiaoàlưu,àgiảiàt à… àth à àthể nới lỏng một số yếu tố.

Facebook tạm khoá tài khoản khi hacker cố t hàđă gà hập nhiều lần

Nh

ữ

ng bi

ệ

n pháp nho nh

ỏ

tă gà ườ

ng b

ả

o m

ậ

t

Một sốđiểm cầ àlưuàýàkh :

 Với các thao tác quan trọ gà hưàđổiàe ail,àđổi pass, xoá nick, cần bắtà gười dùng nhập lại password. Lýà doà l à đ ià khià gười dùng bị chôm cookie, hoặ à lơà l à u à kho à máy. Hãy nhìn Facebook và Google, cả à t a gà à đều bắt ta phải nhập lại mật khẩu khi muố àđổi pass.

 Với các ứng dụng cần bảo mật cao, phải có Two-factor verification (Gửi tin nhắn, device tạo authentication token). Mình hiện tạià ũ gàđa gàd gà ,àd à à ạn có biết mật khẩu Gmail hay WordPress củaà hà ũ gà o àthể oàđă gà hậpàđược.

 Nên khuyến khích (hoặc bắtà u à gười dùng sử dụng mật khẩuàd i,àđiàk à hữ và số, viết hoa viếtàthường và kí tựđặc biệt. Máy móc rất hiệ àđại khi crack mật khẩu, có thể vào đ để test xem máy mấtà aoàl uàđể mò ra mật khẩu của bạn.

 Nếu site của bạn không có HTTPS, hoặc team không có kinh nghiệm làm bảo mật, cứ để cho bọn khác lo. Bạn có thể d gà Oáuth,à hoà ph pà gườiàd gà đă gà hập từ Google, Facebook.

PHẦNà à–àCá“Eà“TUDY

L

Ỗ

H

Ổ

NG B O M

Ậ

T KH NG KHI P C A

LOTTE CINEMA

Đă gà hập là một chứ à ă gàđơ àgiản nhấtà àhơ à %à ứng dụng web cần phải có. Tuy hi ,àđ iàkhiàtaàlạiàkh gàđược hướng dẫn cách thực hiện chứ à ă gà Đă gà hập à ột cách đ gàđắn, bài bản, dẫ àđến những lỗi dở khóc dở ười, hoặc những lỗ hổng bảo mật khủng khiếp. Đến cả Lotte Cinema, mộtàt a gà e àđược khá nhiềuà gười dùng còn mắc lỗiàsơàđẳng này.

Đă gà hậ

p h

ả

? Ch

ỉ

c

ầ

n m

ộ

t b

ả

ng User, hai c

ộ

t Username và Password là xong

1. Người dùng nhập tên tài khoản (email) và mật khẩu.

2. So sánh tên tài khoản và mật khẩu với thông tin trong database.

3. Nếuàđ g,à hoà gườiàd gàđă g nhập,àlưuàth gàti à oàsessio àhoặc cookies.

Bướ à à à àkh gà àg àđ gà ,à hư gà ước 2 mớiàl àđiềuàđ gà i.àĐaàphần tụi mình đều lưuàt ực tiếp tên tài khoản và mật khẩu oàdata ase,àsauàđ àđe à aàsoàs h.

Đ àl à h củ chuối nhất và ngu nhất. Database là một trong nhữ gà ơiàha à ị tấn công, dễ làm thất thoát dữ liệu. Trong quá khứ, lỗi SQL Injection từng làm thất thoát hàng triệu thông ti àkh hàh gà àth gàti à edità a d.àChưaàt hàđến chuyện hacker bên ngoài, nhiều khi thằng Database Admin hứng lên, nó có thể àđược mật khẩu của khách hàng, lớn chuyện

hưa?

C hàlưuàt ữ mật khẩuàđ gàphải là l àsaoàđể chỉ gười dùng mới biếtàđược mật khẩu của họ.àL àsaoàư?àH àđọc phầ àdưới nhé.

V

ậyà àh aàl àđượ

c ch

ứ

gì, l

ắ

m trò!!

Ừ, cách giải quyếtà ũ gkh àđơ àgiản. Bạn có thểd gàh àhashàđể mã hóa mật khẩuà hưà sau:

1. Sử dụ gàh àhashà h à ă àđể mã hóa mật khẩu củaà gười dùng. 2. Lưuàt ữ mật khẩuà àdưới database.

3. Khià gườiàd gàđă gà hập, hash mật khẩuàđ à hập, so sánh với mật khẩuàđ àlưuàdưới database.

C hà àđảm bảo chỉ gười dùng biết mật khẩu của họ, dù là lập trình viên hay database admin, có nắ àđược cả code lẫ àdata aseà ũ gàkh gàt ià oà àra mật khẩu. Tuy nhiên, cách này có một vấ àđề: Hai mật khẩu giống nhau khi hash sẽ có kết quả giống nhau. Hacker có thể mò ra mật khẩu bằng cách dùng dictionary attack – hash toàn bộ các mật khẩu có thể trong từđiển, rồi so sánh kết quả với mật khẩuàđ àhashàdưới database.

Thế hư g,à ỏ quýt dày có móng tay nhọ .àĐ àl à hàlưuàt ữ mật khẩuàđ gà àhiện nay àf a e o kàđều áp dụng:

1. Khi tạo mật khẩu, tạo random một chuỗi kí tự gọi là salt.

2. Salt sẽđược cộng vào sau mật khẩu, toàn bộ chuỗi mật khẩu và salt sẽ bị ă à hash . 3. Lưuàsaltà àgi àt ịđ à ă à uống database (Mộtà gười dùng sẽ có 1 salt riêng).

4. Khià gườiàd gàđă gà hập, lấy salt củaà gười dùng, cộng nó với mật khẩu họ nhập vào, hash ra rồi so với giá trị trong database.

Vớià hà ,àkhià gười dùng quên mật khẩu, hệ thống không tài nào mò ra mật khẩuàđể gửi cho họ. Cách giải quyết duy nhất là reset mật khẩu, random ra một mật khẩu mới rồi gửi cho

gười dùng.

Mấtà àa ou tàl à e à hưà ất sạch sành sanh. Kinh khủ gà hưa! Không tin à, bạn thử ngẩm lại xem, bạn có dùng chung 1 email/mật khẩuà hoàG ail,àFa e ook,àE e ote,à…à à hiều trang khác không?

L

ỗ

h

ổ

ng b

ả

o m

ậ

t kh

ủ

ng khi

ế

p c

ủ

a Lotte Cinema

Mộtà g àđẹp trời nọ,à hàđịnh dẫn gấuàđià e àphi ,àă àuống rồià* eep*.àĐị hàđặt vé online mà quên mất mật khẩu lottecinema.com, mình mò mẫm phầ àđă gà hập, tìm hoài mới thấy mụ à Qu à ật khẩu .àNhậpàđịa chỉ mail và chứng minh nhân dân, mình mau chóng nhận được một email gửi từlotte i e a,àt o gàđ à à ả username và mật khẩu của mình.

Thật là tiệ à u àđià ất, khỏi phải reset mật khẩu. Khoan, có cái gì sai sai ởđ !! Vậy là bọn lotteàlưuàthẳng mật khẩu của mình thẳ gàdưới database à. Lỡ database bị thất thoát dữ liệu là toàn bộ các tài khoản khác củaà hà V à àth hà i àlotteà i e aàkh à ũ gàđiàto gà theo.

TÔI ĐÃ

HACK

“TƠI TẢ”

WEB SITE C

Ủ

A

LOTTE CINEMA NHƯ THÊ

N

A

O?

Làm m ̣t developer có tâm ,àchúng ta không chỉ phảiàđảm bảo code chạ àđược, mà còn phải bảoàđảm v ̀ bảo m ̣t (với các h ̣ th ́ng quan trọng). Có nhi ̀u lúc, l ̃i bảo m ̣tàđ ́n từ chính sự

̉u t_ả của developer. T o gà hươ gà àmình sẽ lôi trang web của Lotte Cinema ra làm m ̃u đ ̉ giải thích cho các bạn.

Lưuàý: Bài vi ́t mang tính ch ́t học thu ̣t, bình lu ̣n v ̀ kĩ thu ̣t. Mình không ủng h ̣, cũng không chịu trách nhi ̣m n ́u bạn mang ki ́n thứ àđ ̀ c ̣p trong bài ra làm chuy ̣n trái pháp lu ̣t! Thân.

Gi

ớ

i thi

ệ

u

Tại sao mình lại chọ àLotteàCi e a?àĐơ àgiản là cách đ à ́y tháng, khi nhắ àđ ́n m ̣t kh ̉u, mì hàđã nêu ra m ̣t l ̃ h ̉ng bảo m t kḥ ủng khi ́p củaàLotteàCi e a:àLưuà ̣t kh ̉uàdưới dạng text.

Đ ́n nay, l ̃ h ̉ng này v ̃ à hưaàđược sửa,àđi ̀u này chứng tỏ hai chuy ̣n: Đ ̣i ngũ l ̣p trình web lotte cinema thi ́u ki ́n thứ à ơà ản v ̀ l ̣p trình và cũng không thèm quan tâm gìđ ́n vi ̣c bảo trì sửa l ̃i.àĐiều này đồ gà ghĩaà ới việc website sẽ có nhiều lỗ hổ gàđể khai thác. Vớiàlogi àđ ,à ình bắtàđầu tìm l ̃ h ̃ng của lotte với tâm th ́ học hỏi. Th ̣t không ngờ, mình tì àđược không chỉ m ̣t, màđ ́n t ̣n vài l ̃ hổng…àcực kì ch ́tà gười, có th ̉ làm toàn b ̣ h ̣ th ́ng ngừng hoạtàđ ̣ng.

B

ắtàđ ̀

u câu c

á

Đ ̀u tiên, hãy nhìn góc trên bên trái trình duy ̣t. M ̣t website không cóhttps,àđ ̀ng nghĩa với vi ̣c toàn b ̣ thông tin bạ à đi ̀n vào (username, password) hoàn toàn có th ̉ bị hacker tr ̣m n ́u bạn dù gà hu gàđường dây mạng/chung wifi vớiàha ke àđó (Xem thêm v ̀ sniffing). Đó là l ́ do các trang ngân hàng, facebook, gmail, thanh toá à đi ̣n từ đ ̀uà đòi hỏi phải dùng https.

Các bạn không nhìn l ̀ àđ u,à hính là username của các bạ àđ ́y? Thôi, chúng ta cứ c ̀u trời là họ lưuàuse a eàđ ̉ nhắc bạn khi bạn c ̀ àđă gà h ̣p lại thui hạ. Thửđ ̉i sang giá trị khác rồi refresh trang xem nào.

Câu nh

̀

m

…à

c

á

m

̣

p

Nhờđ ̉i cookie, mì hàđãha kàđược vào tài khoản gười khác. Ok ngon, có th gàti à gười dùng luôn! Giờ mình thửđ ̉i thông tin xem nào,àđược luôn. Thửđặt vé xem nào, cũ gàđược n ́t!

Có th ̉ dụ d ̃ Lotte Cinema gửi m ̣t kh ̉u cho mình không nhỉ? Thử xem nào,àđ ̉i email của user này sang sang email mì h,àsauàđó báo m ́t m ̣t kh ̉u. Vào email xem sao?

Ồ, nhậ àđược mật khẩu hiện tại luôn, mail của Lotte nhanh thật! Vì m ̣tàuse àthường tái sử dụng m ̣t kh ̉u ở nhi ̀u trang, mình có th ̉ thử dùng username và m ̣t kh ̉u này ở m ̣t s ́ trang khá àđể mò account. Th ́y ch ́tà gườià hưa??

Thửđ ̉i m ̣t kh ̉u hiện tạià e ,àđược luôn. Giờ mì hàđã có th ̉ đă gà h ̣p với m ̣t kh ̉u mới đ ̉i.àĐ àlà l ̃i thứ :àKhiàtha àđ ̉i m ̣t kh ̉u, bắt bu ̣ à gười dùng phảiàđ ̉i m ̣t kh ̉u cũ. Tỉ số giờđã là 2-0 cho Lotte Cinema.

Bonus thêm c

á

voi

Hai lỗi trên đ àđủ là àtơiàtả toàn b ̣ h ̣ th ́ng. Chỉ c ̀n vi ́t một con bot nho nhỏ, l ̀ àlượt thay giá trị membername trong cookie (từ a tới zzzzzzz) là có th ̉ l ́y gầ à hưàtoàn b ̣ thông tin khách hàng, hoặ àđ ̉i toàn bộ pass o dàl à gườiàd gàkh gàđă gà hậpàđược. (Các bạn khác dùng username dài quá thì chịu).

L ̃i XSS này chỉ hi ̣n ra ở m ̃i trang của user nên không th ̉ dùng đ ̉ deface website. Tuy nhiên, mình v ̃n có th ̉ hi ̣n pop-up giả mạo gười dùng tảià i usà hưàhì hàdưới. Dùng JS, mình có thể lấy số thẻ, sốCMNDàđể gườiàd gàti àtưởng rằng message là của lotte.

K ́t hợp vớià o à otàđã nói phía trên, mình hoàn toàn có th ̉ dụ d ̃ rất nhiều gười dùng Lotte tải virus khi họđă gà h ̣p vào h tḥ ́ng. Không còn lời nàoàđ ̉ nói, 3-0 cho Lotte Cinema!

K

ế

t lu

̣

n

Những l ̃i bảo m ̣t mình chỉ ra không có gì cao siêu! Do mình không phải dân chuyên v ̀ bảo m ̣t nên những kĩ thu ̣t t ́n công của mình cũng chỉ dừng ở mức vô cù gà ơà ản. V ́ àđ ̀ của Lotte Cinema làở ch ̃ họ không bi ́t tí gì v ̀ bảo m ̣t , dẫ àđến chuyện h ̣ th ́ng bảo m ̣t quá kém.

Nhưà ác bạ àđã th ́y, hành vi này là sự thi ́u tôn trọng khách hàng và còn có th ̉ gây nguy hại hoà gười dùng. Tuy nhiên, có vẻLotteàCi e aàđã r ́t khôn ngoan trong khâu pháp l ́ khi rũ bỏ mọi trách nhi ̣m trong ph ̀n Thỏa Thu ̣n .àTuy thua 3- à hư gà ̃n không phải chịu trách nhi ̣m gì, hoan hô Lotte Cinema.

Lời khuyên cu ́i cùng: các bạn v ̃n có th ̉ xem phim ởLotte,à hư gđừ gàđi ̀n b ́t kì thông tin cá nhân gì vào cái h ̣ th ́ng trờiàđánh của nó nhé! Thân chào.

Các bạn có thể xem video tóm tắt bài viết ở đ : https://www.youtube.com/watch?v=CtnfOZmKR3A. Nhớ like và subscribe trong link này nhé: https://www.youtube.com/c/toidicodedaoblog?sub_confirmation=1.à M hà đa gà ần

àsu àđể xin Custom U‘Là hoàCha elàT iàĐiàCodeàdạo.

Update (30/08/2016)

LOZI.VN ĐÃ “VÔ Ý” Đ

L

Ộ

D

Ữ

LI

Ệ

U 2 TRI

Ệ

U

NGƯ I DÙNG NHƯ TH

NÀO?

Trong quá trình viết series Bảo mật nhập môn, mình vẫ àha àđià ghịch dạo, tìm lỗi bảo mật dạo theo tinh thầ à odeàdạo à ủa blog. Lẽ tấtà hi ,àđ àt àlỗi thì phải tìm các trang to to, nhiềuà gười dùng một tí, chứ trang nho nhỏ thì ai quan tâm.

L àde elope ,à hàkh gàđủ giỏi về mạng hay hạ tầng để có thể tấn công server hay DDOS gì g àđ .àV à ậy, mình quyếtàđịnh chỉ kiểm tra web và app, hai thứ mình rành nhất. Việt Nam nói là làm, mình bắtàđầu truy cập website của app của 1 số ông lớ à hưàtiki,àlazada,àfood ….

Việc dò lỗià ũ gàgiố gà hưà uà àvậ ,àđ iàkhià uàđược cá bự,àđ iàkhià uà ả buổiàkh gàđược o à o.àK à ,à hà uàđược một con cá nho nhỏ …à gu àhiểm của lozi.vn.

Dò tìm t

ừ

web

Khi vào giao diệ àlozi. ,àđập vào mắt mình là lỗi bự nhất: không có HTTPS! N iàđơ àgiả ,àlướt web có thông tin quan trọ gà àkh gà àHTTPà ũ gàgiố gà hưà à ạ àđià tà a,à hầ ,àđià chịch mà không dùng BCS vậy. Hacker có thể chôm dữ liệu của bạn trong nháy mắt khi bạn không hay biết gì. (Xem thêm vềđộ bảo mật của giao thức HTTP).

Tiếp theo, mình bắtàđầu nghịch ngợm bằ gà hà…à ở Chrome Developer Tool.àĐừng coi thường nó nhé, công cụ à àđạo àlắ àđấy. Chà, thử xem ta có gì nào?