Month: August 2021

Giao thức bảo mật HTTPS và MITM attack(Secure Coding P1)
Giao thức bảo mật HTTPS và MITM attack(Secure Coding P1)

Table of contents
- Giao thức bảo mật HTTPS và MITM attack
- MITM attack với WebProxy
Giao thức bảo mật HTTPS và MITM attack

Như tất cả lập trình viên đều biết: HTTPS là một giao giức bảo mật, dữ liệu được mã hóa trên đường truyền, các bước bắt tay (handshake) để mã hóa được dữ liệu của nó tóm gọn bởi các bước bên dưới

Các bước handshake này sẽ đảm bảo dữ liệu giữa client và server được mã hóa bởi một key mà chỉ có client và server biết. Sẽ không ai có thể đọc trộm hoặc sửa đổi các gói tin giữa client và server

Tuy nhiên, nhìn sơ đồ trên chúng ta có thể thấy mắt xích yếu nhất của các bước HandShake chính là step 1 và step 2

Về mặt logic: Nếu như ở Step 1 client say hello với "ai đó" ko phải server, Step 2 server response với "ai đó" ko phải là client thì sao? nếu như client và sever ko làm làm việc trực tiếp với nhau mà thông qua "ai đó" thì Masterkey ở step 7 đã bị "ai đó" lấy – và "ai đó" có khả năng tóm được gói tin, có khả năng giải mã được gói tin, có khả năng gói tin sẽ bị sửa đổi trong quá trình khi gửi nhận giữa client và server?

Nếu điều này xảy ra, đó chính là MTTM attack – Man In The Middle Attack – một hình thức tấn công chen vào giữa đường truyền để lấy dữ liệu, sửa đổi, giả mạo gói tin

Hầu hết các kết nối hiện tại của web, mobile đều đang sử dụng HTTPS để gửi nhận dữ liệu trên đường truyền. Điều này khiến đại đa số lập trình viên yên tâm và hài lòng với về mức độ an toàn này. Nếu sử dụng cách chặn gói tin thông thường thì cái mà attacker thu được chỉ là một gói dữ liệu đã mã hóa – không có giá trị gì.

Nhưng thực tế có đúng như thế ko?

Không, tất nhiên là không, hiện thực tàn khốc hơn thế rất nhiều

Trên thực tế, dữ liệu gửi từ A sang B trên Internet ko thực sự đi trực tiếp từ A sang B, mà có thể nó sẽ còn phải qua rất nhiều server Trung gian khác.

Quay lại lý thuyết về các bước HandShake – với hai mắt xích yếu nhất là Step1 và Step2 – Giả sử chúng ta lừa được client(ở đây là mobile) rằng ServerXXX mới là con server, lừa nốt server(ở đây là Server mà chúng ta cần kết nối đến) rằng ServerXXX mới là client thì sao?

Bingo!!!

Tức là thực tế dữ liệu đã gửi đến 1 con ServerXXX trung gian, sau đó forward cho client hoặc server – nghĩa là dữ liệu này hoàn toàn có thể được đọc, được giải mã, được sửa đổi ở server ServerXXX?

Chúng ta có thể kiểm chứng suy luận này một cách dễ dàng theo cách bên dưới.

(Mình xin nhấn mạnh lại một lần rằng, đây chỉ là một trò chơi ở level Kiddy có thể dùng trong việc kiểm thử – còn trên thực tế, sẽ tàn khốc hơn thế này rất nhiều. Nên việc chú trọng vào Security khi thiết kế, lập trình ứng dụng là cực kỳ quan trọng)

MITM attack với WebProxy

Chuẩn bị
- Cài Web Proxy trên máy tính: Fiddler (Window), Charles (Mac)
- Chuẩn bị 1 con điện thoại Android
- Kết nối Máy tính, Android vào cùng 1 giải mạng
- Cài đặt proxy của điện thoại Android trỏ vào IP của máy tính: mục đích mọi gói tin đi qua android đều đi qua proxy là máy tính
Mô hình mạng sẽ như sau

Do Mobile nhận PC là proxy, nên toàn bộ việc gửi nhận dữ liệu – nói một cách chính xác là: toàn bộ hoạt động liên quan đến internet của Mobile đều bị Proxy – ở đây là PC giám sát Khi mở Webproxy trên máy tính – ở đây mình dùng Fiddler – chúng ta có thể nhìn thấy các gói tin

Tất nhiên, các gói tin này nếu dùng HTTPS thì sẽ là gói tin mã hóa – Không có giá trị gì

Vậy làm sao để giải mã các gói tin này? Easy, follow 4 steps bên dưới nhé

1. Setting Proxy của điện thoại trỏ vào PC(Giả sử IP của PC là 192.168.0.100)

2. Setting WebProxy để capture HTTPS Connect & Decrypt data

Vào setting của WebProxy, chọn 2 mục
- Capture HTTPS CONNECTs
- Decrypt HTTPS traffic
Sang thẻ connection
- Port :ở đây mình chọn port 8888 – đây chính là port để setup proxy cho Mobile
- Chọn Allow remote computers to connect
3. Export Cert của webproxy và cài vào điện thoại

Export root cert của webproxy sau đó copy vào điện thoại – cài cert như bình thường

Mục đích của việc này chính là để WebProxy và điện thoại có thể "hiểu nhau" – sau hành động mọi kết nối đến internet từ điện thoại – thông qua proxy đã ko còn bí mật – Proxy sẽ nhìn được toàn bộ dữ liệu của điện thoại

4. Kết quả test thử với việc đăng nhập account Fsoft

Dù là giao thức HTTPS nhưng dữ liệu username/password vẫn phơi thân ra như ảnh dưới Mọi người có thể thử với 1 số ngân hàng, ví điện tử, không phải ngân hàng/ví điện tử nào cũng áp dụng các cơ chế để phòng tránh MITM attack. Mình đã thử với 1 số ví điện tử/ngân hàng(mà ko tiện kể tên ra) thì thấy dữ liệu dạng này vẫn phơi thân ra mời gọi đầy quyến rũ 😛

Replay gói tin

Một tính năng cực kỳ hay ho của các tool Web Proxy là chúng ta có thể Replay gói tin, thậm chí sửa dữ liệu trước khi replay. Tức là ví dụ Chuyển 10 đồng thì chúng ta có thể sửa lại thành 200 đồng rồi replay gói tin. Tình cờ 1 cách đen đủi bạn code backend ko tính khả năng này là chúng ta đã có 200 đồng rồi. Đây cũng chính là thủ thuật áp dụng để trick điểm một cách quang minh chính đại trên Server GST – Hero. VD mình chơi được 30 điểm thì mình có thể sửa lại dữ liệu thành 50 điểm rồi đẩy lên server bằng tính năng Replay

Yeah, câu hỏi quan trọng nhất: Phòng chống MITM attack thế nào?

Client(mobile, web..etc) cần làm gì, Server cần làm gì?

Nếu bạn là 1 developer, nếu bạn có nhiều hơn 2 năm kinh nghiệm, nếu lĩnh vực chính của bạn là client server, ví điện tử, financial…etc thì chúng ta sẽ buộc phải quan tâm đến vấn đề này

Mình post bài lấy chỉ tiêu nên chúng ta hẹn nhau ở post sau nhé 😛
August 2, 2021
Software Architecture: Bắt đầu từ đâu? – Part 1
Motivation

Series này hưởng ứng Technopedia, nhưng các bài viết sẽ không phục vụ mục đích dự thi. Đầu tiên mình định viết về Solution Architecture theo quyển Solutions Architect’s Handbook nhưng nghĩ lại thì Software Architecture sẽ hợp lý để bắt đầu hơn.

Disclaimer

Bài viết này không nhằm mục đích hướng dẫn hay đề ra một con đường trong sự nghiệp, chỉ là chia sẻ và những gì mình đã trải nghiệm thôi.

Developer đến Software Architecture

Mọi người sẽ thắc mắc tại sao lại là Developer chứ không phải Coder. Về cơ bản thì Coder – Người code tức là họ chỉ biết hoặc cũng chỉ muốn code (Ở một phương diện nào đó), còn Developer – Người phát triển phần mềm, tức là họ xử lý tất cả các vấn đề liên quan đến quy trình phát triển phần mềm (Software Development Process) từ nói chuyển với stakeholders, thiết kế ứng dụng (ở một mức độ nào đó), deploy phần mềm, debug, sửa lỗi và cải tiến phần mềm. Một cách đơn giản trong đa số trường hợp Coder tương đương với Junior Developer.

Ồ!!!

Vậy Developer sẽ trở thành Software Architecture như nào và điểm khác biệt là gì khi developer đã có thể thiết kế ứng dụng (như mình có nói ở trên). Mình sẽ đưa ra ví dụ như này cho mọi người dễ hình dung:

Trong một dự án xây dựng hệ thống và phần mềm di động đi kèm một chiếc máy ảnh, người dùng có thể download một số sticker và chỉnh sửa lên bức ảnh của mình, Backend sẽ xây dựng một vài API để phục vụ. Trong trường hợp này Developer đã có thể thiết kế được API, kiến trúc của Backend dựa trên ExpressJS, deploy chúng lên AWS, xử lý memcache để tốc độ phản hồi tốt hơn, người dùng nhận được sticker mới ngay khi chúng được upload.

Vậy có thể thấy rằng hầu hết công việc đã được Developer xử lý (ở đây tạm thời không phân chia Junior-Middle-Senior nhé) và dự án golive thành công. 5 tháng sau đội dự án bị đập tơi bời từ khách hàng vì bill từ AWS vài $10000 cho mỗi tháng, trong trường hợp này nếu là bạn Software Architecture sẽ xử lý như nào

(Thực ra có vài cách trong trường hợp này nhưng mình sẽ đưa ra một cách cho thấy sự tương phản nhất) Thay vì đưa trực tiếp API cho Mobile như bạn Software Developer, API sẽ được xử lý như một file tĩnh (JSON-XML) từ S3 cùng với sự hỗ trợ của CDN, file này sẽ được cập nhật khoảng 30′ một lần nếu có sự thay đổi về danh sách sticker. Như vậy người dùng sẽ chờ tối đa khoảng 30′ để có thể nhận được sticker mới, nhưng thay vào đó bill từ AWS sẽ chỉ khoảng $500.

Vậy bạn Developer có thể biết cái gì tối ưu nhất cho hệ thống nhưng sẽ bị hạn chế khi xử lý các vấn đề tradeoffs-đánh đổi. Trong khi đó Architect sẽ cần biết cả 2.

Software architecture?

Đang nói về thiết kế ứng dụng chứ không phải job title nhé :P. Mình sẽ gạch đầu dòng thôi vì chỗ nào cũng có định nghĩa:
- Các tiêu chuẩn, khái niệm tôn chỉ (gì gì đó) của một hệ thống.
- Cách tổ chức, các component quan trọng, cách tương tác, những thành phần nhỏ hơn và interface giữa chúng (không cụ thể nhé).
Về cơ bản thì Software architecture là những hiểu biết chung về thiết kế hệ thống trong dự án phần mềm, tất nhiên sẽ bao gồm cả việc hệ thống được chia nhỏ như nào, và interface giữa chúng là gì nữa, nhưng chỉ dừng lại ở những component và interface mà mọi người đều cần hiểu thôi nhé.

Ví dụ: chi tiết về việc iOS team lưu trữ password hay load thông tin từ database ở local device như nào sẽ không là một phần trong architecture của cả dự án nhưng việc chỉ ra những gì cần lưu trữ ở local như một lớp caching thì lại có.

Ông anh Martin Fowler thì định nghĩa khá đơn giản ở đây:

So, this makes it hard to tell people how to describe their architecture. “Tell us what is important.” Architecture is about the important stuff. Whatever that is.

Vậy cần những gì để trở thành một Software Architecture? Có rất nhiều bài viết nói về cái này, nhưng mình sẽ chỉ ra một số cái mình nghĩ là quan trọng nhất:
- Hard skill hay technical skill gì gì đó:
  
  Bao giờ cũng là các application architecture phổ biến, pattern, anti-pattern, cái này thì thực ra khá dễ để nhìn ra và dễ tiếp cận
  
  Integration architecture, à thì không phải lúc nào cũng xây dựng một cái gì đó từ đầu (from scratch), nên integration luôn là sự lựa chọn tốt.
  
  Enterprise architecture, nó liên quan đến tất cả mọi thứ của một công ty, cá thể kinh doanh, từ chiến lược kinh doanh, mô hình vận hành, hoạt động kinh doanh và cả những thứ liên quan đến IT và Infrastructure nữa, nên nếu có bị giới hạn về mặt hiểu biết, mình có thể sẽ không đi sâu về cái này.
- Soft skill cái này quan trọng này, có thể mọi người sẽ nghĩ đến những thứ khá cao siêu như Leadership hay Organization nhưng mình sẽ đi từ những thứ nhỏ nhỏ trước:
  
  Ra quyết định – Decisions, tất nhiên là bạn cần quyết định nhiều thứ, đặc biệt là về kiến trúc hoặc đơn giản hơn là trong team sẽ làm việc với nhau như nào (communication decision)
  
  Continuous Delivery, nghe có vẻ là hard skill nhưng thực tế là soft skill. Về cơ bản phần mềm hay hệ thống sẽ vẫn là một thứ gì đấy trừu tượng (ở trên bản vẽ – mượn từ archiecture – kỹ sư trong ngành xây dựng), cho đến khi nó được deploy trên môi trường thực tế. Và khi phần mềm được deploy càng sớm và càng liên tục thì việc chứng mình architecture hợp lý càng nhanh và chính xác, mọi người cũng trưởng thành hơn về mặt thực hành.
Bài tiếp theo mình sẽ viết tiếp về các skill nhé.
August 1, 2021