techover.io

Month: December 2019

  • Lan man về trình biên dịch (compiled) và trình thông dịch (interpreted)

    Chắc hẳn các bạn đã rất quen thuộc với 2 cụm từ “trình biên dịch” và “trình thông dịch”.
    Mình xin phép tổng hợp lại và cùng nhau tìm hiểu kỹ hơn một chút nhé.

    Theo SGK Tin học lớp 11:

    Có một vài thứ ta cần bàn đến ở đây.
    Trước hết hãy làm rõ “biên dịch” và “thông dịch”.

    • Biên dịch là chuyển các tài liệu từ ngôn ngữ này sang ngôn ngữ khác, đảm bảo độ chính xác.
    • Thông dịch là chuyển nhanh các thông điệp từ ngôn ngữ này sang ngôn ngữ khác, đảm bảo độ chính xác.
      Người ta đưa thêm một từ “trình” vào trước để ám chỉ rằng, nó là khái niệm dành cho máy để phân biệt với “biên dịch viên” và “thông dịch viên” mà chúng ta vẫn hay dùng cho con người.

    Hãy tưởng tượng xem, trình biên dịch và trình thông dịch làm gì với một đoạn mã lệnh nhé.
    a. Trình biên dịch: lần lượt thực hiện các bước sau:
    B1: Duyệt, kiểm tra, phát hiện lỗi, xác địch chương trình nguồn có dịch được không.
    B2: Dịch chương trình nguồn thành chương trình đích để máy hiểu và lưu trữ lại.
    b. Trình thông dịch: lần lượt thực hiện các bước sau
    B1: Kiểm tra tính đúng đắn của câu lệnh
    B2: Chuyển đổi câu lệnh nguồn thành câu lệnh tương ứng trong ngôn ngữ máy
    B3: Thực hiện các câu lệnh vừa chuyển đổi

    Chung lại, trình biên dịch sẽ chuyển đổi toàn bộ mã nguồn sang mã máy, rồi chứa kết quả vào ổ đĩa cứng để có thể thực thi ở lần chạy sau. Chương trình ngôn ngữ cấp cao được chuyển đổi gọi là chương trình mã nguồn (source program) và chương trình ngôn ngữ máy tạo ra gọi là chương trình đối tượng (object program) hoặc mã đối tượng (objectcode).
    Cách hoạt động của trình thông dịch khác so với trình biên dịch. Thay vì chuyển đổi toàn bộ mã nguồn sang chương trình đối tượng thì cứ khi nào chạy thì trình thông dịch hoạt động chuyển sang mã máy và đưa ra kết quả ngay. Công việc này sẽ diễn ra tương tự ở lần chạy tiếp theo. (theo http://kienthucweb.net/nao-la-trinh-bien-dich-va-thong-dich.html)
    Một vài ngôn ngữ thông dịch phổ biến: PHP, Javascript, Perl, …
    Một vài ngôn ngữ biên dịch phổ biến: C, C++, Java, …
    Vậy thực sự cái gì làm công việc dịch này?
    Cụ thể, trong C là GCC, còn trong PHP là Zen Engine VM.
    Và đây là những gì diễn ra khi chúng ta chạy một đoạn mã PHP, tham khảo bài viết dưới đây:
    https://techmaster.vn/posts/34207/php-chay-nhu-nao-tu-source-code-den-render

    Có 2 thứ ta cần cùng nhau làm rõ hơn đó là, cái đích cuối cùng của cả 2 đều phải tạo ra một thứ ngôn ngữ mà máy phải hiểu và có thể chạy.
    Vậy có 2 vấn đề:

    1. Máy ở đây hiểu là gì?
    2. Thứ ngôn ngữ như thế nào thì máy hiểu?

    Vấn đề thứ nhất, máy chính là CPU (Central Processing Unit), nó chính là bộ xử lý trung tâm, là các mạch điện tử thực hiện các câu lệnh của chương trình bằng cách thực hiện các phép tính số học, logic, so sánh, các hoạt động nhập/xuất dữ liệu (I/O) cơ bản do mã lệnh chỉ ra. (tham khảo: https://vi.wikipedia.org/wiki/CPU)
    Vấn đề thứ 2, ngôn ngữ máy là ngôn ngữ nhị phân (biểu diễn dưới dạng các chuỗi bit 0, 1).

    Lại có câu hỏi khác được nêu ra, tại sao CPU hiểu được các bit 0, 1?
    OK, câu trả lời là: CPU hiểu được vì các bit 0 và 1 biểu diễn cho tín hiệu điện, 1 tương ứng với “bật”, 0 tương ứng với “tắt”.
    Mã máy chạy trong CPU là dãy các tín hiệu xung điện (0 và 1) mà trình biên dịch hoặc trình thông dịch đã tạo ra.

    Một CPU có tầm vài triệu con transistor (hoặc nhiều hơn), hầu hết vai trò của chúng là các cổng logic, làm nhiệm vụ đóng hoặc mở tùy vào tín hiệu xung điện (là 0 hoặc 1).

    Phù, lằng nhằng phết nhỉ. Đến đây mình xin phép dừng lại, vì có quá nhiều thứ phải đọc, phải tìm hiểu. Nhưng ít nhất mình cũng hình dung ra được cái cách mà máy tính nó làm việc khi ta chạy một đoạn mã lệnh.

  • Webservers

    Webservers

    Về cơ bản bài viết này đưa cho các bạn khái niệm rất cơ bản về WebServer, các bạn web developer có thể rất cần Đầu tiên, mình nghĩ chúng ta nên đề cập đến HTTP, làm thế nào để match incoming HTTP request với website, sau đó là 2 Web Server rất phổ biến: Apache và Nginx, cuối cùng sẽ đề cập đến 1 ngôn ngữ cụ thể và cách kết nối với web server ở đây là PHP với PHP-FPM.

    HTTP, Web Server và Web Sites

    Mọi người có lẽ đều nghĩ rằng một WebServer chỉ có thể xử lý phục vụ một trang web, nhưng thực sự là ngược lại. Trong Apache thì dùng khái niệm VirtualHost, còn Nginx sử dụng bằng cách định nghĩa Server trong Nginx Configuration hay còn gọi là Virtual Servers.

    Nếu một WebServer đang xử lý nhiều trang web, làm thế nào để máy chủ định tuyến đến đúng trang web mà người dùng muốn truy cập?

    Chúng ta quay lại với HTTP – HyperText Transfer Protocol, là một trong năm giao thức chuẩn của mạng Internet, giao thức sử dụng để giao tiếp giữa WebServer và WebClient. Về cơ bản, WebServers sẽ đọc Host header của các Web HTTP request, nếu không tồn tại Host header hoặc không phù hợp, WebServer sẽ chuyển yêu cầu đến một trang web mặc định.

    Chúng ta có thể dùng curl để kiểm tra. Ví dụ mình sẽ kiểm tra magz.techover.io và Google.

    Chúng ta có thể thấy IP của WebServer là 104.28.19.140, chúng ta dùng curl để xem response khi gọi đến địa chỉ này.

    Chúng ta có thể thấy là magz.techover.io sử dụng Cloudflare để bảo vệ, và chúng ta bị chuyển đến trang mặc định 403 khi không có quyền truy cập.

    Còn với Google:

    Có thể thấy Google sử dụng GWS – Google Web Server. GWS thông báo cho Client rằng, Client cần phải truy cập đến http://www.google.com thông qua Location Header. Có 2 điều bạn thấy ở đây:

    • http://www.google.com mới là trang mặc định, thay vì http://google.com (cái này liên quan đến một khái niệm khác http://google.com được gọi là Naked Domain Name, sẽ có một bài viết liên quan đến vụ này sau).
    • GWS gửi một response chuyển hướng 301 đến http://www.google.com.

    Bây giờ nếu thêm Host header vào trang web thì sao:

    Kết quả không khả quan lắm, có vẻ như magz.techover.io và google.com vẫn không phải trang mặc định. Với trường hợp của magz.techover.io là do cloudflare chuyển hướng với non-SSL request sang SSL site.

    Đến đây một session mới được khởi tạo với Set-Cookie Header. Chúng ta có thể thử với một static site khác, site này không hề có Set-Cookie Header.

    Phần tiếp theo sẽ nói về việc cài đặt và cấu hình Nginx và Apache cho một hoặc nhiều Website.

  • Cách upload 1 App iOS lên Deploygate

    Cách upload 1 App iOS lên Deploygate

      Xin chào mọi người, hôm nay mình sẽ hướng dẫn các bạn cách upload 1 app lên Deploygate

      Thông thường việc cài đặt ứng dụng sẽ được thực hiện thông qua App Store, tuy nhiên sẽ có một số trường hợp sẽ ta không cần phải đưa app lên App Store mà thiết bị vẫn có thể cài đặt được. đa số sẽ thuộc vào một trong hai trường hợp sau :

      • Testing: Trước khi release app, ta cần test ứng dụng, vì vậy việc cung cấp bản build để tester có thể test trước khi release là một điều cần thiết
      • In-house Applications: Là những ứng dụng chỉ được sử dụng internal trong một công ty hay tổ chức nào đó ( đối với những ứng dụng In-house application, ta cần có tài khoản Apple Developer Enterprise Program)

      Những điều bắt buộc

      1. Valid Apple developer program account (not the Apple Developer Enterprise Program)
      2. Máy tính chạy Mac OS X
      3. Đã cài Xcode

      Tổng quát

      Bên dưới là danh sách các bước bắt buộc để submit 1 app

      1. Tạo 1 record của app trên iTunes Connect
      2. Cấu hình XCode project cho việc distribution
      3. Export ipa file from xcode
      4. Upload app lên deploygate

      1. Tạo 1 record của app trên iTunes Connect Bạn phải tạo 1 record của app trên iTunes Connect trước khi bạn upload app lên App Store. Nó sẽ chứa tất cả thông tin cần thiết để có thể quản lý để xử lý và hiển thị app trên App Store. Xem thông tin chi tiết tại đây

      2. Cấu hình XCode project cho việc distribution Bạn phải nhập các thông tin để chứng thực app: Identity, Team, Bundle ID, import provisioning file, set version number,… Tạo 1 provisiong profile Xem thông tin chi tiết tại đây

      3. Export ipa file from xcode

      – Achieve app: bước đầu tiên bạn tạo 1 bản lưu trữ của app để build và lưu trữ thông tin app.

      • Chọn scheme hiện tại của app: Ở mục Build only device -> Generic iOS Device
      • Sau đó, trên thanh status bar trên cùng, chọn Product -> Archive Rồi đợi Xcode nó archive app, khi xong thì vô Window -> Organizer để xem cái bản mình vừa mới archive được, bạn cũng có thể xem các bản archive trước đó

      – tiếp theo chúng ta export ra file ipa Xem thông tin chi tiết ở đây

      4. Upload app lên deploygate

      bước 1: đăng ký tài khoản deploygate link đăng ký ở đây

      bước 2: sau khi đăng ký xong ta chọn account -> Organizations -> Create

      • tiếp theo ta điền đầy đủ các thông tin ở trong hình -> Create -> Finish

      bước 3 : Sau khi ấn Finish thành công thì việc còn lại của chúng ta là upload file ipa mà chúng ta export từ xcode lên đây

      • chọn upload App -> tìm tới folder lưu file ipa -> open -> upload
      • việc tiếp theo là chờ đợi tới khi việc upload thành công -> sẽ hiển thị ra một màn hình như bên dưới, tới được bước này thì xin chúc mừng các bạn đã upload thành công app của mình lên deploygate rồi đấy ^^
      • muốn lấy link để tải app của mình cho mọi người, ta chọn vào Add a link for sharing -> hệ thống sẽ tự sinh ra cho mình một link để tải app 😀

      Chúc Các bạn thành công ^^

    • Top 10 lỗ hổng bảo mật web phổ biến theo chuẩn OWASP – OWASP TOP 10

      Top 10 lỗ hổng bảo mật web phổ biến theo chuẩn OWASP – OWASP TOP 10

      Dành cho ae lập trình web – Đọc qua mà né

      1. Lỗ hổng Injection (Lỗi chèn mã độc)

      Injection là lỗ hổng xảy ra do sự thiếu sót trong việc lọc các dữ liệu đầu vào không đáng tin cậy. Khi bạn truyền các dữ liệu chưa được lọc tới Database (Ví dụ như lỗ hổng SQL injection), tới trình duyệt (lỗ hổng XSS), tới máy chủ LDAP (lỗ hổng LDAP Injection) hoặc tới bất cứ vị trí nào khác. Vấn đề là kẻ tấn công có thể chèn các đoạn mã độc để gây ra lộ lọt dữ liệu và chiếm quyền kiểm soát trình duyệt của khách hàng.

      Mọi thông tin mà ứng dụng của bạn nhận được đều phải được lọc theo Whitelist. Bởi nếu bạn sử dụng Blacklist việc lọc thông tin sẽ rất dễ bị vượt qua (Bypass). Tính năng Pattern matching sẽ không hoạt động nếu thiết lập Blacklist.

      Cách ngăn chặn lỗ hổng:

      Để chống lại lỗ hổng này chỉ “đơn giản” là vấn đề bạn đã lọc đầu vào đúng cách chưa hay việc bạn cân nhắc  liệu một đầu vào có thể được tin cậy hay không. Về căn bản, tất cả các đầu vào đều phải được lọc và kiểm tra trừ trường hợp đầu vào đó chắc chắn đáng tin cậy.(Tuy nhiên việc cẩn thận kiểm tra tất cả các đầu vào là luôn luôn cần thiết).

      Ví dụ, trong một hệ thống với 1000 đầu vào, lọc thành công 999 đầu vào là không đủ vì điều này vẫn để lại một phần giống như “gót chân Asin”, có thể phá hoại hệ thống của bạn bất cứ lúc nào. Bạn có thể cho rằng đưa kết quả truy vấn SQL vào truy vấn khác là một ý tưởng hay vì cơ sở dữ liệu là đáng tin cậy. Nhưng thật không may vì đầu vào có thể gián tiếp đến từ những kẻ có ý đồ xấu. Đây được gọi là lỗi Second Order SQL Injection.

      Việc lọc dữ liệu khá khó vì thế các bạn nên sử dụng các chức năng lọc có sẵn trong framework của mình. Các tính năng này đã được chứng minh sẽ thực hiện việc kiểm tra một cách kỹ lưỡng. Bạn nên cân nhắc sử dụng các framework vì đây là một trong các cách hiệu quả để bảo vệ máy chủ của bạn.

      2. Broken Authentication

      Đây là nhóm các vấn đề có thể xảy ra trong quá trình xác thực. Có một lời khuyên là không nên tự phát triển các giải pháp mã hóa vì rất khó có thể làm được chính xác.

      Có rất nhiều rủi ro có thể gặp phải trong quá trình xác thực:

      • URL có thể chứa Session ID và rò rỉ nó trong Referer Header của người dùng khác.
      • Mật khẩu không được mã hóa hoặc dễ giải mã trong khi lưu trữ.
      • Lỗ hổng Session Fixation.
      • Tấn công Session Hijacking có thể xảy ra khi thời gian hét hạn của session không được triển khai đúng hoặc sử dụng HTTP (không bảo mật SSL)…
      • …

      Cách ngăn chặn lỗ hổng:

      Cách đơn giản nhất để tránh lỗ hổng bảo mật web này là sử dụng một framework. Trong trường hợp bạn muốn tự tạo ra bộ xác thực hoặc mã hóa cho riêng mình, hãy nghĩ đến những rủi ro mà bạn sẽ gặp phải và tự cân nhắc kĩ trước khi thực hiện.

      3. Lỗ hổng XSS (Cross Site Scripting)

      Sơ đồ quá trình tấn công XSS

      Lỗ hổng XSS (Cross-scite Scripting) là một lỗ hổng rất phổ biến. Kẻ tấn công chèn các đoạn mã JavaScript vào ứng dụng web. Khi đầu vào này không được lọc, chúng sẽ được thực thi mã độc trên trình duyệt của người dùng. Kẻ tấn công có thể lấy được cookie của người dùng trên hệ thông hoặc lừa người dùng đến các trang web độc hại.

      Cách ngăn chặn lỗ hổng:
      Có một cách bảo mật web đơn giản đó là không trả lại thẻ HTML cho người dùng. Điều này còn giúp chống lại HTML Injection – Một cuộc tấn công tương tự mà hacker tấn công vào nội dung HTML – không gây ảnh hưởng nghiêm trọng nhưng khá rắc rối cho người dùng. Thông thường cách giải quyết đơn giản chỉ là Encode (chuyển đổi vê dạng dữ liệu khác) tất cả các thẻ HTML. Ví dụ thẻ <script> được trả về dưới dạng <script&gt.

      4. Insecure Direct Object References

      Đây là trường hợp điển hình của việc cho rằng đầu vào của người dùng là tin cậy từ đó dẫn đến lỗ hổng bảo mật. Lỗ hổng này xảy ra khi chương trình cho phép người dùng truy cập các tài nguyên (dữ liệu, file, database). Nếu không thực hiện quá trình kiểm soát quyền hạn (hoặc quá trình này không hoàn chỉnh) kẻ tấn công có thể truy cập một cách bất hợp pháp vào các dữ liệu nhạy cảm, quan trọng trên máy chủ.

      Chúng ta có thể xem xét ví dụ sau:

      Một đoạn mã có module download.php và cho phép người dùng tải tệp xuống sử dụng tham số CGI. Ví dụ download.php?file=something.txt. Do sai sót của nhà phát triển, việc kiểm tra quyền hạn đã bị bỏ qua. Kẻ tấn công có thể sử dụng lỗ hổng này để tải về bất kì tệp nào trên hệ thống mà ứng dụng có quyền truy cập. Chẳng hạn như code ứng dụng, hoặc các dữ liệu khác trên máy chủ.

      Một ví dụ phổ biến khác là chức năng đặt lại mật khẩu dựa vào đầu vào của người dùng để xác định mật khẩu đặt lại. Sau khi nhấp vào URL hợp lệ, kẻ tấn công có thể sửa đổi trường tên người dùng trong URL để “đóng giả” admin.

      Cách ngăn chặn lỗ hổng: Thực hiện phân quyền người dùng đúng cách và nhất quán với sự áp dụng triệt để các Whitelist.

      5. Security Misconfiguration

      Trong thực tế, máy chủ website và các ứng dụng đa số bị cấu hình sai. Có lẽ do một vài sai sót như:

      • Chạy ứng dụng khi chế độ debug được bật.
      • Directory listing
      • Sử dụng phần mềm lỗi thời (WordPress plugin, PhpMyAdmin cũ)
      • Cài đặt các dịch vụ không cần thiết.
      • Không thay đổi default key hoặc mật khẩu
      • Trả về lỗi xử lý thông tin cho kẻ tấn công lợi dụng để tấn công, chẳng hạn như stack traces.

      Cách ngăn chặn lỗ hổng:
      Có một quá trình “xây dựng và triển khai” tốt (tốt nhất là tự động). Cần một quá trình audit các chính xác bảo mật trên máy chủ trước khi triển khai.

      6. Sensitive data exposure (Rò rỉ dữ liệu nhạy cảm)

      Lỗ hổng này thuộc về khía cạnh crypto và tài nguyên. Dữ liệu nhạy cảm phải được mã hóa mọi lúc, bao gồm cả khi gửi đi và khi lưu trữ – không được phép có ngoại lệ. Thông tin thẻ tín dụng và mật khẩu người dùng không bao giờ được gửi đi hoặc được lưu trữ không được mã hóa. Rõ ràng thuật toán mã hóa và hashing không phải là một cách bảo mật yếu. Ngoài ra, các tiêu chuẩn an ninh web đề nghị sử dụng AES (256 bit trở lên) và RSA (2048 bit trở lên).

      Cần phải nói rằng các Session ID và dữ liệu nhạy cảm không nên được truyền trong các URL và cookie nhạy cảm nên có cờ an toàn.

      Cách ngăn chặn lỗ hổng:

      • Sử dụng HTTPS có chứng chỉ phù hợp và PFS (Perfect Forward Secrecy). Không nhận bất cứ thông tin gì trên các kết nối không phải là HTTPS. Có cờ an toàn trên cookie.
      • Bạn cần hạn chế các dữ liệu nhạy cảm có khả năng bị lộ của mình. Nếu bạn không cần những dữ liệu nhạy cảm này, hãy hủy nó. Dữ liệu bạn không có không thể bị đánh cắp.
      • Không bao giờ lưu trữ thông tin thẻ tín dụng, nếu không muốn phải đối phó với việc tuân thủ PCI. Hãy đăng ký một bộ xử lý thanh toán như Stripe hoặc Braintree.
      • Nếu bạn có dữ liệu nhạy cảm mà bạn thực sự cần, lưu trữ mã hóa nó và đảm bảo rằng tất cả các mật khẩu được sử dụng hàm Hash để bảo vệ. Đối với Hash, nên sử dụng bcrypt. Nếu bạn không sử dụng mã hoá bcrypt, hãy tìm hiểu về mã Salt để ngăn ngừa rainbow table attack.

      Không lưu trữ các khóa mã hóa bên cạnh dữ liệu được bảo vệ. Việc này giống như khóa xe mà cắm chìa luôn ở đó. Bảo vệ bản sao lưu của bạn bằng mã hóa và đảm bảo các khóa của bạn là riêng tư.

      7. Missing function level access control (lỗi phân quyền)

      Đây chỉ là sai sót trong vấn đề phân quyền. Nó có nghĩa là khi một hàm được gọi trên máy chủ, quá trình phân quyền không chính xác. Các nhà phát triển dựa vào thực tế là phía máy chủ tạo ra giao diện người dùng và họ nghĩ rằng khách hàng không thể truy cập các chức năng nếu không được cung cấp bởi máy chủ.

      Tuy nhiên, kẻ tấn công luôn có thể yêu cầu các chức năng “ẩn” và sẽ không bị cản trở bởi việc giao diện người dùng không cho phép thực hiện các chức năng này. Hãy tưởng tượng trong giao diện người dùng chỉ có bảng điều khiển/admin và nút nếu người dùng thực sự là quản trị viên. Không có gì ngăn cản kẻ tấn công phát hiện ra những tính năng này và lạm dụng nó nếu không phân quyền.

      Cách ngăn chặn lỗ hổng: Ở phía máy chủ, phải luôn được phân quyền một cách triệt để từ khâu thiết kế. Không có ngoại lệ – mọi lỗ hổng sẽ dẫn đến đủ các vấn đề nghiêm trọng.

      8. Cross Site Request Forgery (CSRF)

      Đây là một ví dụ của cuộc tấn công deputy attack. Trình duyệt bị đánh lừa bởi một số bên thứ ba lạm dụng quyền hạn. 
      Ví dụ: trang web của bên thứ ba gửi yêu cầu đến trang web đích (ví dụ: ngân hàng của bạn) sử dụng trình duyệt của bạn với các dữ liệu như cookie và phiên người dùng. Nếu bạn đang đăng nhập vào một trang trên trang chủ của ngân hàng và trang đó dễ bị tấn công, một tab khác có thể cho phép kẻ tấn công đóng giả người quản trị. Deputy là khi trang web lạm dụng quyền hạn của mình (session cookies) để làm điều gì đó mà kẻ tấn công yêu cầu.

      Chúng ta có thể xem xét ví dụ sau:

      • Kẻ tấn công là Alice chọn mục tiêu là chiếc ví của Todd bằng cách chuyển một phần tiền của Todd cho cô ta. Ngân hàng của Todd đã gặp phải lỗ hổng CSRF. Để gửi tiền, Todd phải truy cập vào URL sau:
      • Sau khi URL này được mở ra, một trang thành công được trình bày cho Todd và việc chuyển đổi đã hoàn tất. Alice cũng biết rằng Todd thường ghé thăm một trang web dưới quyền kiểm soát của cô tại blog.aliceisawesome.com, nơi cô đặt đoạn mã sau đây:
      <img src = "http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243" width = "0" height = "0" />
      • Khi truy cập trang web của Alice, trình duyệt của Todd nghĩ rằng Alice liên kết đến một hình ảnh và tự động đưa ra yêu cầu HTTP GET để lấy “hình ảnh”, nhưng điều này thực sự hướng dẫn ngân hàng của Todd chuyển $1500 đến Alice.

      Cách ngăn chặn lỗ hổng:

      Lưu trữ một Token bí mật trong một trường form ẩn mà không thể truy cập được từ trang web của bên thứ ba. Tất nhiên bạn phải xác minh trường ẩn này. Một số trang web yêu cầu mật khẩu của bạn cũng như khi sửa đổi các cài đặt nhạy cảm.

      9. Using component with known vulnerabilities

      Đây là vấn đề xảy ra khi sử dụng các bộ thư viện đã tồn tại lỗ hổng. Trước khi tích hợp một mã nguồn mới vào website, hãy thực hiện một số nghiên cứu hoặc kiểm tra bảo mật. Sử dụng mã nguồn mà bạn nhận được từ một người ngẫu nhiên trên GitHub hoặc một số diễn đàn có thể rất thuận tiện. Nhưng hãy sẵn sàng trước nguy cơ đối diện với một lỗ hổng bảo mật web nghiêm trọng.

      Ví dụ: Nhiều trường hợp, trang admin bị lộ không phải vì các lập trình viên sai sót, mà vì phần mềm của bên thứ ba vẫn chưa được cập nhật. Nếu bạn nghĩ rằng họ sẽ không tìm thấy cài đặt phpmyadmin ẩn của bạn, hãy tìm hiểu về dirbuster.

      Cách ngăn chặn lỗ hổng:

      Chú ý cẩn thận khi sử dụng các thành phần của bên thứ 3, không nên là một coder copy-paste. Kiểm tra cẩn thận các đoạn code quan trọng của bạn. Nếu các đoạn code này có lỗ hổng, tin tặc có thể đọc cơ sở dữ liệu, tệp tin cấu hình, mật khẩu… của bạn.

      • Cập nhật mọi thứ: Đảm bảo bạn đang sử dụng phiên bản mới nhất của tất cả mọi thứ và có kế hoạch cập nhật chúng thường xuyên. Ít nhất là đăng ký bản tin về các lỗ hổng bảo mật mới liên quan đến sản phẩm.

      10. Unvalidated redirects and forwards

      Đây lại là vấn đề về lọc đầu vào. Giả sử rằng trang đích có một mô-đun redirect.php lấy URL làm tham số. Thao tác với tham số này có thể tạo ra một URL trên targetite.com chuyển hướng trình duyệt đến địa chỉ malwareinstall.com. Khi người dùng nhìn thấy liên kết, họ sẽ thấy liên kết targetite.com/blahblahblah tin cậy và truy cập vào. Họ ít biết rằng địa chỉ này thực ra chuyển tới trang nhúng phần mềm độc hại (hoặc bất kỳ trang độc hại khác). Ngoài ra, kẻ tấn công có thể chuyển hướng trình duyệt sang targetite.com/deleteprofile?confirm=1.

      Cách ngăn chặn lỗ hổng:

      • Không sử dụng chức năng chuyển hướng.
      • Có một danh sách tĩnh các vị trí hợp lệ để chuyển hướng đến.
      • Có Whitelist tham số người dùng xác định.

      Tổng hợp các cộng cụ quét lỗ hổng website tốt nhất

    • Cách fix lỗi unzip cho những folder tiếng Nhật

      Cách fix lỗi unzip cho những folder tiếng Nhật

      Mô tả lỗi:   

      Bạn nhận được 1 folder tiếng Nhật và sau khi dùng phần mềm giải nén thì tên file sẽ biến thành như này: âlâCâïâvâèâôâ^âAâvâèÄÄì∞èJö¡_î⌐É╧éαéΦîƒôóê╦ùèÅæ

      Nguyên nhân:

      Đó là do win của bạn chưa hỗ trợ định dạng cho tiếng Nhật.

      Cách fix:

      Mình đang dùng Win10 nên mình sẽ hướng dẫn các bạn fix trên win10 nhé. Các version khác các bạn cũng tìm cách fix tương tự.

      Bước 1: Vào Control Panel

      Bước 2: Chọn Clock and Region => sau đó chọn Region

      Bước 3: Chọn Adminstrative

      Bước 4: Chọn Change system locale … sau đó change thành (Japanese (Japan))

        Bước 5: Click OK và restart lại PC

        Kết luận

        Hy vọng với tip này sẽ giúp được một cơ số bạn và dự án tránh được bài toán khó chịu này.

      • Tổng quan về Mobile App

        Tổng quan về Mobile App

        Ghi chú:  Bài viết này chỉ là một góc nhìn chủ quan của tác giả về mảng mobile app. vì vậy có gì không đúng mọi người có thể đóng góp ở phần comment nhé!! Thank.

        Mở đầu:
        Ở thời điểm hiện tại việc xây dựng ứng dụng native không phải là lựa chọn duy nhất để tạo lên một một ứng dụng mobile app. Ngày nay chúng ta có thể dựa vào yêu cầu của khách hàng, các chức năng của sản phẩm để lựa chọn được hướng đi phù hợp hơn. Ta có thể dựa trên vào công nghệ web (HTML5, CSS3 và JavaScript) đang phát triển mạnh mẽ trên mobile. Hoặc tận hưởng những lợi ích của các công cụ phát triển đa nền tảng như React Native hoặc Flutter. Dưới đây, bạn sẽ tìm thấy chìa khóa để giải quyết vấn đề khó khăn này khi chọn phương pháp phát triển ứng dụng di động.

        Native App

        Native app hay còn được gọi là ứng dụng gốc. Vốn dĩ nó có cái tên này là bởi vì nó được viết bằng chính các ngôn ngữ lập trình gốc thần nhất dành riêng cho từng nền tảng cụ thể. Hai nền tảng di động phổ biến nhất hiện nay là Android và iOS (Windows Phone thì đã bị khai tử vào tháng 10/ 2017 ). Từ đó, các ngôn ngữ lập trình tương ứng được chính các công ty mẹ tạo ra phù hợp với từng nền tảng. Chẳng hạn như Apple đã có Swift, Objecive-C được dành cho lập trình ứng dụng trên nền tảng iOS. Lập trình trên Android thì dùng Java, mặc dù đây không phải ngôn ngữ do Google tạo ra.

        Viết Native App nghĩa là lập trình viên sẽ sử dụng IDE, SDK mà nhà sản xuất cung cấp để lập trình ra một ứng dụng, build ứng dụng đó thành file cài và gửi lên App Store để kiểm duyệt. Người dùng sẽ phải tìm ứng dụng trên App Store, tải về máy và chạy.  

        Với những hệ thống lớn, cần đồng bộ, ta vẫn phải viết phần back-end trên server. Server sẽ đưa ra một số API. Native app lấy dữ liệu về máy, truyền dữ liệu lên server thông qua các API này.

        Ưu điểm

        • Tận dụng được toàn bộ những tính năng của device: Chụp ảnh, nghiêng máy, rung, GPS, notification.
        • Có thể chạy được offline.
        • Performance rất nhanh vì code native sẽ được chạy trực tiếp.
        • UX phù hợp với từng nền tảng
        • Là lựa chọn duy nhất cho các ứng dụng game, xử lý hình ảnh hay video …

        Khuyết điểm

        • Cần cài đặt nặng nề (Android Studio, XCode, Android SDK, …), khó tiếp cận.
        • Với mỗi hệ điều hành, ta phải viết một ứng dụng riêng. Khó đảm bảo sự đồng bộ giữa các ứng dụng (1 button trên Android sẽ khác 1 button trên iOS, pop cũng khác).
        • Cần phải submit app lên App Store, mỗi lần update phải thông báo người dùng.
        • Code mệt và lâu hơn so với Mobile Web dẫn đến một khuyết điểm là chi phí phát triển cao.

        Kĩ năng cần có

        • Ngôn ngữ lập trình: Java / Kotlin cho Android, Objective-C / Swift cho iOS
        • Kiến thức chuyên sâu về ứng dụng: View, Action, Adapter trong Android …
        • Cách xây dựng Web Serivce, Restful API, cách gọi API từ device, …

        __________________________________________________________________________

        Hybrid App

        Hybrid App kết hợp những ưu điểm của Mobile Web và Native App. Ta xây dựng một ứng dụng bằng HTML, CSS, Javascript, chạy trên WebView của mobile. Tuy nhiên, Hybrid App vẫn có thể tận dụng những tính năng của device: chụp hình, GPS, rung, ….

        Hybrid App sẽ được viết dựa trên một cross-platform framework: Cordova, Phonegap, Ionic …. Ta sẽ gọi những chức năng của mobile thông qua API mà framework này cung cấp, dưới dạng Javascript. Bạn chỉ cần viết một lần, những framework này sẽ tự động dịch ứng dụng này ra các file cài đặt cho Android, iOS . Một số ứng dụng không quá nặng về xử lý, cần tận dụng chức năng của device sẽ chọn hướng phát triển này.

        Ưu điểm

        • Chỉ cần biết HTML, CSS, JS .
        • Viết một lần, chạy được trên nhiều hệ điều hành
        • Tận dụng được các chức năng của device.

        Khuyết điểm

        • Không ổn định, khó debug. Framework sẽ dịch code của bạn thành code native, việc sửa lỗi ứng dụng khá khó vì bạn không biết code sẽ được dịch ra như thế nào.
        • Performance chậm.
        • Cần cài đặt nhiều thứ (phải cài đặt SDK này nọ thì mới build ứng dụng được).

        Kiến thức cần biết

        • HTML, CSS, Javscript cơ bản.
        • Cách dùng một số framework CSS, Javascript: jQuery Mobile, Ionic Framework, AngularJS, Bootstrap, …
        • Kiến thức về các cross-platform framework: Cordova, Phonegap…
        • Cách xây dựng Web Serivce, Restful API, cách gọi API từ device, … (Hybrid app cũng sẽ kết nối với server thông qua API như Native App).

        __________________________________________________________________________

        Cross-Platform App

        Được sinh ra nhằm mục đích để giải quyết bài toán hiệu năng của Hybrid và bài toán chi phí khi mà phải viết nhiều loại ngôn ngữ native cho từng nền tảng di động. Nhưng chúng ta lại hay nhầm lẫn giữa Hybrid App và Cross-Platform App, trên thực tế thì chúng khác hoàn toàn nhau. Có lẽ, đặc điểm chung duy nhất giữa chúng là khả năng chia sẻ source code. Lập trình viên chỉ cần lập trình một lần và biên dịch hoặc phiên dịch ra thành nhiều bản Native App tương ứng với từng nền tảng khác nhau.

        Công cụ quan trọng nhất để thực hiện các dự án ứng dụng đa nền tảng (Cross Platform) chính là Frameworks đa nền tảng. Có rất nhiều Framework đa nền tảng. Mỗi loại sẽ có những điểm mạnh và điểm yếu khác nhau. Tùy vào mục tiêu xây dựng App mà lập trình viên sẽ lựa chọn Framework nào cho phù hợp.

        Nổi tiếng và phổ biến nhất là Framework Xamarin. Ngôn ngữ lập trình chủ đạo trong Xamarin là C#, ngoài ra còn có Objective-C, Swift và Java. Ngoài ra, còn một số cái tên mà khá hot đó là React-Native (thằng này có ông bô là Facebook ), Flutter (thằng này có ông bác là Google)…

        Ưu điểm

        • Tận dụng được những tính năng của device: Chụp ảnh, nghiêng máy, rung, GPS, notification.
        • Hiệu năng tương đối ổn định.
        • Tiết kiệm tiền.
        • Hiệu quả về mặt thời gian khi mà bạn muốn phát triển một ứng dụng nhanh chóng.
        • Trải nghiệm người dùng tốt hơn là hybrid app.

        Nhược điểm

        • Hiệu năng sẽ thấp hơn với app native code.
        • Khó học vẫn đòi hỏi kiến thức native code.
        • Vẫn còn có hạn chế từ framework

        Kĩ năng cần có

        • Kiến thức C# (đối với Xamarin ), JS (đối với React-Native ), Dart(đối với Flutter) Objective-C, Swift và Java cơ bản.
        • Kiến thức về một số framework React-Native, Xamarin …

        __________________________________________________________________________

        Web App

        Hướng Mobile Web thường được áp dụng khi các bạn đã có sẵn một website đang hoạt động. Ta sẽ tạo thêm 1 trang web riêng cho mobile, sử dụng HTML, CSS, một số framework hỗ trợ mobile và responsive (Bootstrap, jQuery Mobile, Materialize). Người dùng sẽ trang web dành cho mobile để dùng ứng dụng.

        Các xử lý khác liên quan đến backend như database sẽ được thực hiện phía trên server. Với một số framework như Angular, VueJS … một trang web có thể giống y hệt một ứng dụng di động thật sự.

        Ưu điểm

        • Chỉ cần có kiến thức về web là viết được
        • Viết một lần, chạy được trên mọi hệ điều hành
        • Người dùng không cần phải cài app, có thể vào thẳng trang web
        • Không cần phải thông qua App Store, tiết kiệm tiền
        • Dễ nâng cấp (Chỉ việc nâng cấp web là xong)

        Nhược điểm

        • Với một số máy đời cũ, Web App sẽ bị bể giao diện, hiển thị sai, hoặc javascript không chạy.
        • Performance chậm
        • Không thể tận dụng được các tính năng của di động: Push notification, chụp hình, nghiêng máy, định vị GPS…

        Kĩ năng cần có

        • Kiến thức HTML, CSS, Javascript cơ bản.
        • Kiến thức về một số framework responsive/mobile như: jQuery Mobile, Bootstrap, …
        • Một số framework javascript để viết Single Page Application: AngularJS, VueJS, …

        Kết Bài

        Sorry các bạn bài viết hơi dài, sau khi nhìn tổng quan về mobile app thì các bạn đã chọn cho mình hướng đi nào chưa? còn mình thì sẽ tiếp tục theo hướng Cross-Platform app.
        Cảm ơn các bạn đã đọc đến đây nhé.

        Tham khảo: https://railsware.com/blog/native-vs-hybrid-vs-cross-platform/

      • Unsubscribing from RxJS Observables with Angular

        Unsubscribing from RxJS Observables with Angular

        Có thể bạn đã biết …

        Problem

        Đối với Angular thì RxJS như là xương sống của ứng dụng vậy. RxJS sử dụng khái niệm Observables và Observers, trong đó thì Observables là data sources và Observer là người dùng data. Mỗi khi Observable trả về values, thì ngay lập tức nó sẽ inform cho Observer và các Observer này sẽ sử lý dữ liệu trả về thông qua các operator. Làm việc với Observables nếu không khéo sẽ có khả năng gây memory leak cho ứng dụng. Đó là khi bạn subscribe 1 Observable mà sau đó không unsubscribe nó.

        Solution

        Ta sẽ phải thủ công unsubscribe tất cả các custom Observables trong khi destroyed các component/directive. Nơi tốt nhất để unsubscribe đó là handle trong function handle event OnDestroy. Tuy nhiên, để có thể tự động unsubscribe các subscriptions có 3 cách sau đây:

        • unsubscribe thông qua subscription object
        • takeUntil operator
        • async pipe

        Unsubscribe

        export class UnsubscribeCardComponent implements OnInit, OnDestroy {
  message: string;
  subscription: Subscription;
  constructor(private upperCaseService: UpperCaseService) {}
 
  ngOnInit() {
    this.subscription = this.upperCaseService.getUpperCaseMessage()
      .subscribe((message: string) => this.message = message);
  }
 
  ngOnDestroy(): void {this.subscription.unsubscribe();}
}

        Cách này là dùng 1 đối tượng Subscription để hold resource và dispose nó khi gọi hàm unsubscribe.

        TakeUntil

        export class TakeUntilCardComponent implements OnInit, OnDestroy {
  message: string;
  private unsubscribe$ = new Subject();
  constructor(private upperCaseService: UpperCaseService) {}
 
  ngOnInit() {
    this.upperCaseService.getUpperCaseMessage()
      .takeUntil(this.unsubscribe$)
      .subscribe((message: string) => this.message = message);
  }
 
  ngOnDestroy(): void {
    this.unsubscribe$.next();
    this.unsubscribe$.complete();
  }
}

        takeUntil sẽ nhận Observable như là 1 tham số, và nó sẽ hủy subscription khi Observable bắn ra giá trị hoặc bị terminate

        AsyncPipe

        export class AsyncPipeCardComponent implements OnInit {
  messageSubscription: Observable<string>;
  constructor(private upperCaseService: UpperCaseService) {}
 
  ngOnInit() {
    this.messageSubscription = this.upperCaseService.getUpperCaseMessage();
  }
}

HTML template:
<p>{{messageSubscription | async}}</p>

        async pipe sẽ subscribe tới 1 Observable và trả về giá trị mới nhất khi nhận được từ Observable ném ra. Khi component bị destroyed thì async pipe sẽ tự động unsubscribe.

        Kết luận

        Khi 1 component/directive bị destroyed, tất các các custom Observable cần phải có thao tác unsubscribe. Qua qua trình tìm hiểu, cũng như làm Angular mình nhận thấy là: Async pipe là solution tốt nhất vì mọi thì đều tự động được thực hiện, tuy nhiên không phải hoàn cảnh nào cũng dùng async pipe được. Khi không dùng được async pipe bạn hãy chuyền qua dùng takeUntil operator.