29/10/2019

So sánh giấy phép mã nguồn mở Apache, MIT, GPL

Mã nguồn mở ngày nay đã và đang trở nên phổ biến hơn bao giờ hết, những dự án mã nguồn mở có thể được tìm thấy hầu như ở bất kì đâu trên không gian mạng rộng lớn này. Tuy nhiên dù có “mở” đi chăng nữa thì những phần mềm mã nguồn mở phải tuân theo những giấy phép nhất định. Điển hình là 3 loại giấy phép phổ biến nhất là Apache, MIT và GPL. Vậy, giữa chúng có gì khác nhau.


Trước hết, giấy phép mã nguồn mở là một loại giấy phép được sử dụng cho các phần mềm mã nguồn mở. Giấy phép này cho phép bất kì cá nhân hay tổ chức nào cũng có thể nghiên cứu, thay đổi, chỉnh sửa và cải tiến phần mềm, và phân phối ở các dạng khác nhau như thay đổi hoặc chưa thay đổi.

Giấy phép Apache
Giấy phép Apache ra đời bởi Quỹ Phần mềm Apache (Apache Software Foundation - ASF). Đây là một giấy phép phần mềm tự do, không có copyleft, bắt buộc trong việc thông báo bản quyển và lời phủ nhận. Giấy phép này hoạt động như các giấy phép phần mềm mã nguồn mở khác, trao cho người sử dụng phần mềm quyền tự do trong bất kỳ mục đích nào, từ chỉnh sửa, thay đổi, phân phối hoặc phân phối bản có sửa đổi của phần mềm theo các điều khoản đã ghi của giấy phép mà không lo lắng tới phí bản quyền.
Được phần đông người dùng đánh giá là giấy phép không có nhiều ràng buộc nên Apache là một giấy phép được sử dụng rộng rãi. Theo số liệu đã được thống kê, đến tháng 10 năm 2012, đã có đến 8708 dự án đặt tại SourceForge.net được cấp phép theo các điều khoản của Giấy phép Apache. Sự phổ biến này đã được trình bày rõ ràng trong một bài viết trên blog vào tháng 5 năm 2008, Google đã liệt kê đến hơn 25000 trong tổng số 100000 dự án đặt trên Google Code đang sử dụng giấy phép này. 

Các điều khoản giấy phép Apache
Trong mỗi tập tin được cấp phép, bất kỳ bản quyền, bằng sáng chế hay thương hiệu và thông báo ghi công phải được giữ nguyên trong các đoạn mã khi phát hành và phải thông báo các tập tin đã thay đổi trong source code.

Nếu có một tập tin NOTICE trong bản phân phối gốc thì các phiên bản sau chỉnh sửa phải kèm theo nội dung của tập tin nêu trên bên trong phần mềm, hoặc tài liệu hướng dẫn sử dụng, hoặc trong một giao diện của phiên bản hiện hành. 
Trừ khi có thông báo đặc biệt nào khác từ ASF thì bất kỳ đóng góp chỉnh sửa nào gửi cho người cấp phép đều sẽ tuân theo các điều khoản của giấy phép mà không cần thông qua bất cứ điều kiện gì nhưng vẫn giữ được sự hợp tác thỏa thuận giữa các bên trong phần đóng góp này.

Giấy phép MIT
Giấy phép MIT được tạo ra bởi Viện Công nghệ Massachusetts (MIT) danh tiếng. Là một loại giấy phép cấp phép, không có copyleft và c rất ít hạn chế trong việc sử dụng, trở thành một trong những giấy phép lý tưởng trong việc phát triển phần mềm. Sự phổ biến của giấy phép này đã được minh chứng bằng việc GitHub, trang web lưu trữ source code nổi tiếng, đã xác nhận rằng đây là giấy phép phổ biến nhất trên dịch vụ của họ, vượt xa các biến thể giấy phép GPL( sẽ đề cập sau) và các giấy phép phần mềm tự do nguồn mở (FOSS) khác. MIT đã tạo tiền để cho các dự án mà ắt hẳn bạn đã nghe qua một lần như: Ruby on Rails, Node.js, jQuery và X11 hay X.

Các điều khoản giấy phép MIT
Các điều khoản của giấy phép MIT được gói gọn rằng: "Quyền hạn sử dụng được trao cho người sử dụng với không hạn chế nào, kể cả quyền sử dụng, sao chép, chỉnh sửa, kết hợp, xuất bản, phân phối, hay phân phối dưới các dạng phiên bản sửa đổi khác nhau, và bán bản sao chép của phần mềm nhưng với điều kiện như: những file ghi về tác giả, người có công (như file NOTICE), file ghi về quyền hạn sử dụng phải được bao gồm trong các phiên bản sử dụng giấy phép này".

Giấy phép GPL
Giấy phép GPL hay còn được biết đến với cái tên GNU General Public License (GNU GPL/GPL) là một giấy phép mã nguồn mở có copyleft được sử dụng rộng rãi, đảm bảo cho người dùng khả năng chạy, nghiên cứu, tùy biển về phần mềm, là sản phẩm trí tuệ của Richard Stallman của Quỹ Phần mềm Tự do (FSF) cho dự án GNU, hỗ trợ cấp cho người nhận chương trình máy tính quyền của Định nghĩa Phần mềm Tự do.

Nhờ có copyleft mà GPL đã trở thành Giấy phép mã nguồn mở phổ biến nhất trong lĩnh vực phầm mềm tự do và nguồn mở. Các sản phẩm tiêu biểu được tạo ra theo giấy phép GPL có thể kể đến như nhân Linux và Bộ biên dịch GNU hay GCC. Nhờ giấy phép này mà nhân Linux đã có những thành công rực rỡ trên con đường phát triển của mình. 

Các điều khoản của giấy phép GPL
GNU GPL cho đến nay đã trải qua 3 phiên bản gồm 17 điều khoản như được tự do chạy chương trình dưới bất cứ mục đích nào, tự do tìm hiểu các hoạt động của chương trình và tự do thực hiện các thay đổi, chỉnh sửa lên nó và quyền truy cập mã nguồn là điều kiện bắt buộc cho quyền tự do này, tự do tái phân phối bản sao, tự do trong việc cải tiến, phát hành cải tiến ra công cộng, tạo điều kiện thuận lợi cho kỹ thuật phân tích ngược (reverse engineeing).

Kết luận
Có thể thấy rằng nhờ có các giấy phép mã nguồn mở mà ngành phần mềm đã và đang trở nên phát triển mạnh hơn bao giờ hết. Các giấy phép tuy khác nhau nhưng đều có điểm chung trong việc tạo điều kiện chỉnh sửa cho nhà phát triển, tạo cơ hội cải tiến chương trình, làm đa dạng hóa chương trình gốc, giúp từng byte, từng bit người sử dụng tương tác trở nên hoàn hảo hơn bao giờ hết.

Theo: TKT

28/10/2019

New Cache Poisoning Attack Lets Attackers Target CDN Protected Sites


A team of German cybersecurity researchers has discovered a new cache poisoning attack against web caching systems that could be used by an attacker to force a targeted website into delivering error pages to most of its visitors instead of legitimate content or resources.

The issue could affect sites running behind reverse proxy cache systems like Varnish and some widely-used Content Distribution Networks (CDNs) services, including Amazon CloudFront, Cloudflare, Fastly, Akamai, and CDN77.

In brief, a Content Distribution Network (CDN) is a geographically distributed group of servers that sit between the origin server of a website and its visitors to optimize the performance of the website.

A CDN service simply stores/caches static files—including HTML pages, JavaScript files, stylesheets, images, and videos—from the origin server and delivers them to visitors more quickly without going back to the originating server again and again.

Each of the geographically distributed CDN server, known as edge nodes, then also shares the exact copy of the cache files and serve them to visitors based on their locations.

Generally, after a defined time or when manually purged, the CDN servers refresh the cache by retrieving a new updated copy of each web page from the origin server and store them for future requests.

How Does CPDoS Attack Work Against CDNs?

Dubbed CPDoS, short for Cache Poisoned Denial of Service, the attack resides in the way intermediate CDN servers are incorrectly configured to cache web resources or pages with error responses returned by the origin server.

The CPDoS attack threatens the availability of the web resources of a website just by sending a single HTTP request containing a malformed header, according to three German academics, Hoai Viet Nguyen, Luigi Lo Iacono, and Hannes Federrath.

"The problem arises when an attacker can generate an HTTP request for a cacheable resource where the request contains inaccurate fields that are ignored by the caching system but raise an error while processed by the origin server."

Here's how the CPDoS attack works:
- A remote attacker requests a web page of a target website by sending an HTTP request containing a malformed header.
- If the intermediate CDN server doesn't have a copy of the requested resource, it will forward the request to the origin web server, which will get crash due to the malformed header.
- As a consequence, the origin server then returns an error page, which eventually gets stored by the caching server instead of the requested resource.
- Now, whenever legitimate visitors try to obtain the target resource, they will be served the cached error page instead of the original content.
- The CDN server will also spread the same error page to other edge nodes of the CDN's network as well, rendering targeted resources of the victim's website unavailable.

"It is worth noting that one simple request is sufficient to replace the genuine content in the cache by an error page. This means that such a request remains below the detection threshold of web application firewalls (WAFs) and DDoS protection means, in particular, as they scan for large amounts of irregular network traffic."

"Moreover, CPDoS can be exploited to block, e.g., patches or firmware updates distributed via caches, preventing vulnerabilities in devices and software from being fixed. Attackers can also disable important security alerts or messages on mission-critical websites such as online banking or official governmental websites."

3 Ways to Launch CPDoS Attacks

CDN Services Vulnerable to CPDoS Attacks
Researchers carried out three attacks against different combinations of web caching systems and HTTP implementations and found that Amazon's CloudFront CDN is the most vulnerable to the CPDoS attack.

"We analyze the caching behavior of error pages of fifteen web caching solutions and contrast them to the HTTP specifications. We identify one proxy cache product and five CDN services that are vulnerable to CPDoS."

The complete results of their tests are as follows:

To be noted, sites running behind some of the listed CDN services are vulnerable because of their own misconfiguration that doesn’t prevent caching servers from storing error pages, and due any weakness in the respective CDN service.

Theo: THN

23/10/2019

Website giả mạo Cổng thông tin điện tử của Bộ Công an, phát tán mã độc

Trang web có địa chỉ http://113113vn.com không thuộc hệ thống tên miền của các tổ chức Chính phủ tại Việt Nam, giả mạo Cổng thông tin điện tử của Bộ Công an.

Sáng 23-10, Công an Đà Nẵng vừa phát cảnh báo về website mạo danh http://113113vn.com, địa chỉ IP 45.76.234.141, được các đối tượng lập nên để phát tán mã độc.


Cụ thể, khi truy cập "Phần mềm giám sát an toàn" tại website mạo danh trên, người dùng có nguy cơ tải về tệp "vn.apk". Đây là tệp chứa mã độc, có thể chiếm quyền điều khiển thiết bị của người truy cập, đánh cắp toàn bộ thông tin, dữ liệu quan trọng như định vị, giám sát cuộc gọi, đọc trộm tin nhắn, kết nối internet…cũng như các dữ liệu lưu trữ trong thiết bị.

Quan sát nhanh, website được thiết kế theo giao diện cho thiết bị cầm tay, phần dưới cùng ghi địa chỉ của Công an TP Đà Nẵng (80 Lê Lợi, phường Thạch Thang, quận Hải Châu), máy chủ của website đặt tại Mỹ.

Công an Đà Nẵng khuyến cáo người dân, tổ chức không truy cập vào trang web này. Trường hợp đã tải tệp tin "vn.apk" trên thiết bị di động thì nhanh chóng gỡ bỏ, xóa tệp tin để tránh bị cài mã độc.

Theo: NLĐ

18/10/2019

Khi Cookie Hijacking + HTML Injection trở nên nguy hiểm


Hôm nay mình sẽ chỉ với các bạn cách mà mình gặp một lỗi html injection, và cách mình biến nó thành lỗi nghiêm trọng với kĩ thuật cookie hijacking.


Đôi điều về HTML Injection và Cookie Hijacking:

HTML injection là một lỗi giúp hacker có thể chèn được mã HTML vào website và thực thi đoạn mã đó trên trình duyệt của người dùng. Lỗi này có thể dẫn tới rất nhiều hệ lụy kể cả việc đánh cắp cookie.


Session Hijacking là hình thức tấn công vào phiên làm việc giữa client và server cách đánh cắp cookie của người sử dụng sau khi họ đã qua bước xác thực với máy chủ, sau đó sẽ chiếm quyền điều khiển của phiên làm việc này


Giai đoạn 1: Khám phá

Lần này mình đã thực hiện test lần lượt trên từng input ở trang người dùng. Nhận thấy rằng các đoạn input đã không được validate như mong đợi. Tuy nhiên làm sao để có thể khai thác lỗi này khi mà cần phải đăng nhập thì mới hiện ra những thông tin này?

Lần 1: Thử khai thác bằng lỗi CSRF, gửi một đoạn code để đăng nhập vào tài khoản cho victim

Ex:


Không quá khó để đoán trước kết quả, cách thực hiện này không thành công vì server đã thực hiện validate login bằng token.

Lần 2:

Cookie Hijacking! Tới cách này thì mình đã thành công vì cookie quản lí phiên đăng nhập không hề hết hạn sau khi mình bấm Logout. Cookie chỉ được xóa khi mình xóa nó bằng tay:I logged in with a test account and then I clicked "logout". Note in the screenshot below that cookies were still stored in the browser after the logout:

Cookie not expired when click logout.

Mình copy cookie bằng Edit This Cookie (edit this cookie - Chrome), sửa lại và nhanh chóng được chuyển tới trang người dùng:


Như vậy là xong! Giờ đã đến lúc khai thác lỗi HTML Injection.

Như mình đã nói ở trên, trường "customer_name" dính lỗi không validate input. Để xác thực việc này, mình đã intercept request bằng burp suite và dán 1 thẻ H1 vào ô name:


Như vậy là đã xong!

Bài viết mang tính chất tham khảo với mục đích học tập!

Chúc bạn thành công <3

Source: Medium