Lỗ hổng bảo mật Cross-Site-Scripting (XSS) có gì nguy hiểm?

Mỗi khi đăng những bài writeup về một lỗ hổng XSS được phát hiện trên một trang web nào đó, tôi biết sẽ có những người nhếch mép cười khẩy vì lúc đó trong đầu họ sẽ nghĩ:

• "Cái lỗi XSS này thì có cái quái gì nguy hiểm cơ chứ?"
• "Ngoài việc hiện lên một hộp thoại thì XSS làm được cái đếch gì nữa không?"
• "Một lỗ hổng vớ vẩn thôi mà. Ơ mà hiện hộp thoại cũng được gọi là lỗ hổng hả?"
• ...

Vậy thì, XSS có gì nguy hiểm?

Thay vì viết ra đống lý thuyết nhàm chán, chúng ta sẽ cùng xem xét những hình thức tấn công khai thác XSS đã được áp dụng trong thực tiễn. Nói trước để những bạn nào còn chưa biết về XSS thì nên Google xem nó là gì trước khi đọc tiếp bài viết này nha.
Read More

Parcelable vs Serializable trong Android

Chào các bạn!

Khi bắt đầu với lập trình Android, chúng ta đều được học rằng KHÔNG THỂ truyền tham chiếu của một đối tượng (object references) tới các Activity hoặc fragment. Để đối mặt với vấn đề khó khăn này chúng ta phải "gói" chúng vào một Intent/Bundle.

Truyền những tham số có kiểu nguyên thủy (primitive data types) như là string, integer, float,... qua Intents thì khá dễ dàng trong Android. Tất cả những gì bạn cần làm là "put" dữ liệu với một key duy nhất làm từ khóa vào Intent và gửi nó đến một Activity bất kỳ.

Nhìn vào API, ta nhận ra rằng có hai cách để truyền Java object qua Intent: một là implements Java class đó từ Percelable interface, hai là implements từ Serializable interface. Là một lập trình viên Java/C# chúng ta chắc hẳn đã biết rõ cơ chế hoạt động của Serializable, vậy tại sao ta lại phải bận tâm với Parcelable?

Để trả lời câu hỏi đó, hay tiếp cận rõ hơn để xem tại sao như vậy nhé!

SERIALIZABLE - BẬC THẦY CỦA SỰ ĐƠN GIẢN

Serializable là một interface chuẩn của Java. Vẻ đẹp của Serializable là việc bạn đơn giản chỉ cần đánh dấu một class Serializable bằng cách implements interface đó lên nó và các class con của nó, sau đó máy ảo Java (Java Virtual Machine) sẽ tự động serialize class theo từng trường hợp khác nhau. Đây là một marker interface, nghĩa là không cần phải cài đặt lại bất cứ method nào của khi implements.


Vấn đề xảy ra với hướng tiếp cận này là Java Reflection được sử dụng, và nó làm tiến trình của phần mềm bị chậm đi. Cơ chế này thường hay tạo rất nhiều đối tượng tạm (temporary object) và khi đó cơ chế dọn rác Garbage Collection của Java sẽ hoạt động và tốn tài nguyên máy tính.


PARCELABLE - ÔNG VUA TỐC ĐỘ

Parcelable là một interface riêng của Android, nơi mà bạn phải tự cài đặt các hàm serialization một cách thủ công mà không được sự hỗ trợ từ JVM. Parcelable được tạo ra cải tiến từ Serializable, nó hiệu quả hơn và khắc phục được một số vấn đề tồn tại ở Java Serializable, đó là lý do tại sao đa phần lập trình viên Android ưu tiên sử dụng Parcelable hơn là Serializable.


Theo những gì mình đọc trên StackOverflow, hay theo các google engineers thì đoạn code trên sẽ chắc chắn thực thi nhanh hơn. Một trong các lý do đó là chúng ta đã cài đặt tường minh các hàm thể hiện quá trình serialization thay vì sử dụng Java Reflection. Khi tối ưu hóa như vậy thì cơ chế dọn rác GC của Java sẽ làm việc ít hơn làm chương trình "nhanh" hơn.

Tuy nhiên, rõ ràng cái gì cũng có cái giá của nó. Với hướng tiếp cận này chúng ta sẽ sinh ra một "đống" code khá phức tạp và làm cho những class này rất khó đọc và fix bug, bảo trì.


KẾT QUẢ KIỂM TRA TỐC ĐỘ

Dĩ nhiên, chúng ta đều muốn biết Parcelable nhanh hơn tới mức nào!

Phương pháp:
- Mô phỏng quá trình truyền object vào activity
- Chạy quá trình đó trong vòng lặp 1000 lần
- Chạy trung bình 10 lần khác nhau để tính dung lượng bộ nhớ, cpu chiếm dụng,..
- Các object được test là HCMUSDeveloper và IceTeaVietDeveloper ở trên.
- Test trong nhiều thiết bị android (LG Nexus 4 - Android 4.2.2, Samsung Nexus 10 - Android 4.2.2, HTC Desire Z - Android 2.3.3)

Kết quả:

Thời gian thực thi của bộ test (hình ảnh và dữ liệu theo developerphil.com)

Nexus 10
Serializable: 1.0004ms, Parcelable: 0.0850ms - 10.16x improvement.

Nexus 4
Serializable: 1.8539ms - Parcelable: 0.1824ms - 11.80x improvement.

Desire Z
Serializable: 5.1224ms - Parcelable: 0.2938ms - 17.36x improvement.


TỔNG KẾT

Trong ví dụ trên, Android Parcelable tỏ ra nhanh hơn nhiều so với kỹ thuật Java Serializable. Một trong những lý do chính là do Parcelable hoàn toàn tùy chỉnh code, cho phép lập trình viên convert dữ liệu cần thiết thành Parcel trong khi Serialazation convert đối tượng thành một data stream sử dụng Java Reflection API.

Nếu bạn muốn trở thành một lập trình viên giỏi, hãy bỏ thời gian để cài đặt Parcelable bởi vì nó có thể thực thi nhanh hơn từ 4 - 10 lần và sử dụng ít tài nguyên hơn, khiến GC hoạt động ít hơn.

Tuy nhiên trong nhiều trường hợp, sự "chậm chạp" của Serializable không đáng nhắc tới. Hãy thoải mái sử dụng nó đối với những class nhỏ, nhưng hãy nhớ là nó luôn "ngốn tài nguyên" nên hãy giảm thiểu đến mức đáng kể khi cần những đoạn code đẹp - dễ đọc và bảo trì. Còn nếu bạn đang muốn truyền một List với hàng nghìn object, thì sự "chậm chạp" đó sẽ lên tới con số nhiều giây. Và khi đó chuyển động giao diện cũng như hiệu năng của ứng dụng sẽ trở nên khá tồi tệ và đó cũng là lúc bạn cần dùng đến vị cứu tinh dành riêng cho lập trình viên Android - Parcelable.

________________________________________________________________________

Trên là những chia sẻ của mình về hai hướng tiếp cận cho việc truyền object ref. Cảm ơn các bạn đã theo dõi, chúc các bạn học tốt và hãy để lại bình luận bên dưới nhé! 
Bonus cho các bạn 1 tấm hình từ slide của anh Huynh Q. Thao về những tip trong Android Perfomance, đó cũng là lý do và động lực để mình viết bài này :D

Tôi đã hack VietDesigner.net và Kenhsinhvien.vn như thế nào?

Hành trình truy tìm lỗ hổng bảo mật

Trước hết, tớ xem xét đặc điểm chung của cả hai trang web này:

1. Đây đều là 2 diễn đàn lớn (mục tiêu càng lớn, càng nhiều người dùng thì càng tỉ lệ thuận với sự nguy hiểm của một lỗi bảo mật được phát hiện).
2. Cùng sử dụng nền tảng Xenforo.
3. Cùng sử dụng một add-on giống nhau để tạo trình chuyển hướng liên kết.

Trong 3 đặc điểm này thì điều thứ 3 chính là mấu chốt:

• http://kenhsinhvien.vn/redirect/?url=https://junookyo.blogspot.com/
• http://forum.vietdesigner.net/redirect/?url=https://junookyo.blogspot.com/

Tại sao tớ biết rằng 2 trang cùng dùng một add-on? Ngoài việc dựa theo cấu trúc liên kết, thì tớ xem mã nguồn trang chuyển hướng của cả 2 và cùng một thấy từ khóa quan trọng sau:

Tìm từ khóa đó trên Google:

Như vậy có thể đoán được 2 diễn đàn kia đang sử dụng add-on tạo trình chuyển hướng tên là "GoodForNothing Url Anonymizer" (sau này đã đổi tên thành GoodForNothing Link Proxy).
Read More

Thiết kế và Con người (phần 1)

Bất cứ nơi đâu chúng ta đến, ta đều bị vây quanh bởi những thiết kế tồi tệ - từ chỗ ngồi của máy bay làm biến dạng tư thế ngồi của chúng ta đến một chiếc xe máy với thiết kế khiếm nhã. Những cảnh quan đã từng là màu xanh của sự sống và bây giờ một màu xám xịt đang dần phủ lên. Môi trường xung quanh của chúng ta chứa đầy những cơ hội bị bỏ lỡ để đem đến sự hài lòng, phấn khích và niềm vui cho cuộc sống con người!

Chỗ ngồi máy bay làm biến dạng tư thế ngồi

Những đồ vật với thiết kế tồi tệ làm chúng ta chậm lại, và làm phiền lòng mọi người - giống như tòa nhà xấu xí của ông hàng xóm làm bạn nhăn nhó mỗi khi nhìn thấy nó, hay cái remote TV với quá nhiều nút bấm, hay chỉ là một phần mềm không thể hoạt động đúng như chức năng của nó.
Những thứ như vậy đa phần là hậu quả của sự hiểu lầm, tham lam, không đồng cảm, thiếu tập trung. Những thiết kế tồi tệ đặc biệt làm phiền lòng con người khi ảnh hưởng rất nhiều tới hành tinh xanh này. Nói có hơi quá, nhưng đôi khi nó có vẻ như đang lấp đầy thế giới này bằng rác rưởi linh tinh.

Cùng với sự trưởng thành của nền công nghiệp thông tin, chúng ta đã chứng kiến sự quan tâm và đầu tư nhiều hơn cho việc thiết kế. Nhiều công ty hiện giữ vững quan điểm cho rằng thiết kế có thể trở thành lợi thế trong việc cạnh tranh với các đối thủ khác. Những hiểu biết của con người về ý nghĩa của "thiết kế" ngày càng trở nên sâu sắc qua từng năm tháng, vượt qua cả thẩm mỹ để đến với những kỹ năng giải quyết vấn đề. Trong những thập kỷ gần đây, trong ngành công nghiệp phần mềm chúng ta cho rằng một sản phẩm là "thiết kế toàn diện" khi sản phầm đó được cho rằng hữu dụng, dễ dùng và hấp dẫn khách hàng. Chúng ta có thể làm tốt hơn vậy - chúng ta cần làm tốt hơn vậy!

Tôi đang muốn ám chỉ điều gì? Trước khi chúng ta đi sâu vào vấn đề, hay để tôi cung cấp cho bạn một vài bối cảnh bằng cách quay trở lại và review những cấp độ khác nhau mà thiết kế có thể được hiểu.


Thiết kế = Hình mẫu

Hầu hết mọi người đều cho rằng thiết kế thì thường liên quan đến thẩm mỹ. Những nguyên tắc phổ quát của cái đẹp, như là Tỉ lệ vàng (Golden Ratio), quy tắc 1/3 (Rule of Thirds) hay là những quy tắc của sự tương đối, căn chỉnh liên kết, tương phản và sự lặp lại thông báo cho tiềm thức của chúng ta rằng vật đó có đẹp hay không. Ở mức độ hiểu biết này đối với thiết kế, chúng ta sẽ nghĩ rằng thiết kế là vẻ ngoài của đồ vật, ví dụ như chiếc xe hơi trông có vẻ chạy nhanh, có vẻ đắt hay có vẻ rất cứng cáp,...

Thiết kế = Chức năng

Tuy nhiên thiết kế không phải chỉ là vật thế đó trông như thế nào mà còn là nó hoạt động như thế nào. Chúng ta xem một vật thể là "thiết kế toàn diện" không chỉ khi nó đẹp mà còn khi nó dễ sử dụng. Thiết kế tốt sẽ giúp cuộc sống chúng ta dễ dàng hơn. tiết kiệm thời gian hơn, và giúp ta không cần phải suy nghĩ nhiều, từ đó giảm thiểu stress trong cuộc sống và giữ gìn ý chí và thiện chí đối với những người xung quanh. Trong trường hợp này, thiết kế  giống như là một cái tủ lạnh - khi nó hoạt động thì mảy may chẳng ai chú ý, nhưng khi nó ngừng hoạt động thì mọi thứ trở nên tệ hại cả lên!

Ở bài tiếp theo mình sẽ đưa đến một khía cạnh hoàn toàn khác của thiết kế, các bạn hay đón xem nhé!

Bài viết dựa trên "Design and the self" của blogger Irene Au

Giải quyết vấn đề thực tế: Khôi phục logo clan CF

Tình huống thực tế

Thử thách gặp phải ở đây là: Từ phiên bản 1151 (cập nhật từ năm 2014) thì CF đã chuyển hệ thống quản lý Clan vào trong game thay vì quản lý trực tiếp trên web như trước. Do đó, chúng ta không thể sử dụng chức năng tìm ảnh qua Google hay tìm trực tiếp từ trang quản lý Clan của VTC Game.
Read More

Truyện ngành CNTT: Tâm sự của một người trái ngành

Chuyện thứ nhất: Chọn ngành

Cách đây 2 năm, cuối năm 12, mình may mắn pass cả 3 vòng lấy học bổng FPT, mình bắt đầu đứng giữa 3 sự chọn lựa: hoặc chọn sư phạm, hoặc chọn nhạc viện, hoặc chọn ĐH FPT và cả 3 đều là đam mê, sở thích của mình.
Read More

1937cn tấn công Vietnam Airlines - Nhận định từ các chuyên gia bảo mật

Bài viết này tổng hợp lại đánh giá từ các chuyên gia bảo mật có uy tín ở Việt Nam về vụ việc nhóm hacker 1937cn đến từ Trung Quốc tấn công vào hãng hàng không Vietnam Airlines.
Read More