Đổi Tên Facebook 1 chữ 2019

Read More

Các lỗi bảo mật cơ bản mà các developer hay gặp

Mở bài

Chào các thành viên Kipalog :D

Mình không biết viết văn, nên câu chữ lủng củng, mong mọi người hiểu được =))

Mục đích bài viết này là chia sẻ đến các Developer (Dev), đặc biệt là các bạn Dev ít kinh nghiệm về vấn để bảo mật cho ứng dụng web.

Kiến thức mình có hạn, nên không nói sâu được, nên mình xin được chia sẻ những kiến thức mình có về các lỗi cơ bản mà rất hay gặp mà các Dev gần như sẽ gặp trong kiếp Coder của mình :D
Mình sẽ không giải thích dài dòng, các bạn chủ động hỏi thằng bạn thân Google để tìm hiểu thêm

Link cho các bạn tham khảo, các bài viết chi tiết và đầy đủ về từng phần
https://kipalog.com/posts/Gioi-thieu-Ebook-tu-viet--Bao-Mat-Nhap-Mon---Bao-Mat-Co-Ban-cho-Developer
https://kipalog.com/posts/Bao-mat-co-ban---Gioi-thieu-ve-SQL-Injection
https://kipalog.com/posts/Lo-hong-bao-mat-Cross-Site-Scripting--XSS--co-gi-nguy-hiem

Lan man xíu

Điều gì ở ứng viên mà mình quan tâm nhất?

Mình thỉnh thoảng có phụ trách tuyển dụng PHP cho nhóm Sản phẩm của công ty. Yếu tố quan trọng nhất cho một ứng viên PHP với mình là gì. Tất nhiên del phải là bảo mật mà là trung thực và chịu khó =)). Nhưng tư duy và tư duy bảo mật là số 2, kiến thức thì học sau

Các điểm chung của các lỗi bảo mật này là gì?

Mình cho là mình tin tưởng về các Input mà client gửi lên (cứ nghĩ input đó là ok rồi). Nên chốt là del bao giờ tin những gì thằng Client gửi lên hết => Phải xử lý input client gửi lên trước khi xử lý việc khác

Thân bài

Các lỗi bảo mật dễ mắc phải

Mình xếp theo mức độ nguy hiểm giảm dần, theo quan điểm cá nhân mình xD

1, SQL Injection

Không phải nói nhiều về cái lỗi thần thánh này, gần như Dev mới 96.69 đều mắc phải nó -_- thậm chí các Dev có kinh nghiệm cũng có thể mắc :D

Lấy ví dụ phần login cho một website nha
- Lỗi xảy ra như thế nào

Câu query bạn mong muốn sẽ là
$sql = "select * from users where username='".$_POST['username']."' and password='".$_POST['password']."'"; // :D
Còn gì tuyệt vời hơn nếu người dùng nhập, ví dụ username là quydo, mật khẩu là matkhauManhVL

Nhưng vấn đề là nhiều thanh niên không thích thế, ví dụ nhập username là quydo' or 1-- - và mật khẩu là nhập linh ta linh tinh đi kadslfjladsjfkldsfjladskfjaskldfjadsklf
Khi đó query mà bạn đang chờ sẽ là

$sql = "select * from users where username='quydo' or 1 limit 1-- - and password='kadslfjladsjfkldsfjladskfjaskldfjadsklf'
Câu query luôn đúng bởi -- - là dùng để kết thúc 1 câu query, như // trong php đó

- Sự nguy hiểm
user chạy ở đây là user connect tới database server (không phải user của web server)

• Thứ nhất là có thể truy xuất gần như là toàn bộ thông tin về cơ sở dữ liệu đang thao thác
  và có thể các database (do grant quyền)
• Thứ hai là có thể query insert, update, drop đến database hiện tại :D ví dụ có thanh niên chạy drop database database_name thì thôi xong (cái này phụ thuộc nhiều yếu tố mới thành công)
• Thứ 3 là có thể upload backdoor (cụ thể là php shell), phải phụ thuộc khá nhiều điều kiện
  user chạy là root (hoặc user có quyền với file), biết được cấu trúc website đang chạy (ví dụ biết được /var/www/domain.com), cái này mà được thì rất nguy hiểm

Thường thì các attacker sẽ tìm phần login admin => login vào admin backend, dựa vào các bug (chủ yếu là upload) để upload backdoor (php shell) lên :D.

2, XSS

Lấy ví dụ phần search cho một website nha
- Lỗi xảy ra như thế nào

Giả sử url trang search là
http://domain.com/search.php?keyword=user_keyword
Và trong trang search.php, và ở trang search.php bạn có dòng
echo "Kết quả tìm kiếm cho từ khóa: ".$_GET['keyword'];
Nếu người dùng nhập keyword bình thường ví dụ: xem phim xxx, maria ozawa gì đó thì ok

Nhưng nếu người dùng thích nhập khác, ví dụ:
Thì lúc load trang search.php?keyword=
1 cái alert bằng javascript sẽ xuất hiện với nội dung "aloxo xss"

- Sự nguy hiểm
Bạn tham khảo đây https://kipalog.com/posts/Lo-hong-bao-mat-Cross-Site-Scripting--XSS--co-gi-nguy-hiem

Thường thì các form input hay bị như thông tin tài khoản, phần bình luận comment :D
Mình cũng bị dính vụ comment lúc mới Dev, có thanh niên làm cái insert 10k có cái alert javascript vào -_-

3, Upload

Lỗi xảy ra như thế nào

Dev không check kiểu file, hoặc chỉ check ở máy client
Ví dụ check kiểu file = javascript trước khi gửi lên là móm, có thể chỉnh sửa js nên bypass được
Code check không chính xác, có thể bypass được, ví dụ dùng cái này là móm ngay
if($FILES['file_field']['type'] == 'jpg') echo "tiếp tục";
Không thay đổi tên, lấy tên theo tên client gửi lên. Người dùng có thể cho tên file là shell.php.jpg, backdoor.php.rar... Có 1 bug mà rất nguy hiểm, dựa vào hàm moveuploaded_file để upload php backdoor lên

link đây http://www.paulosyibelo.com/2015/03/exploiting-php-upload-forms-with-cve.html

4, Insecure Direct Object References

Cái này cũng khá hay gặp, nhất là ở phần API, bạn xem tham khảo của #toidicodedao link mình gửi trên đó, có phần này, rất hay và chi tiết. Hoặc bài của anh Juno_okyo về trang web CGV film đó :D
Hoặc ví dụ mà cái anh gì bên VNsecurity ví dụ về site bán vé online lớn nhất VN tickets gì đó ở Trà đá hacking lần 2

Ví dụ ở cái app đi, sẽ có 1 API /user/transaction/Trans_id để lấy info giao dịch của người dùng
user gọi api, api get thông tin giao dịch có id=Trans_id để trả lại cho user, ok :D
Lỗi ở đây là Dev không kiểm tra cái Trans_id có thuộc về user đó không
Nên có thể thay Trans_id khác, mà API vẫn trả về :D

5, Remote Code Execution

Để chạy được cái này khá nhiều điều kiện, bạn có thể search Google để biết thêm chi tiết

6. Remote file inclusion

Giờ cái này khá hiếm, nếu mà được thì nguy hiểm, khi file include là con backdoor shell

Các lỗi mà bạn không hiểu thì chịu khó Google để tìm hiểu nha. 4 cái đầu là nguy hiểm nhất nên mình có ví dụ cơ bản :D

Mọi người có ý kiến đóng góp gì thì comment để mình fix lại

Văn vẻ lủng củng mọi người thông cảm =))

Read More

NOSQL có đồng nghĩa với NO Injection?

NOSQL có đồng nghĩa với NO Injection?

Chắc hẳn chúng ta đã khá quen thuộc với khái niệm SQL Injection đây là một lỗi hổng phổ biến nhất cũng như nguy hiểm nhất với các trang web trên Internet. "Gần đây" với sự phất triển của những loại database mới như graph database và NoSql đã làm phong phú hơn lựa chọn dataabase của các dự án phàn mềm.

Với những ưu điểm của mình như:

• Mã nguồn mở
• khả năng mở rộng linh hoạt
• Phù hợp với điện toán đám mây và bigData.

các csld NoSql như MongoDb hay redis là những lựa chọn đáng để cân nhắc với những hệ thống lớn, những một khía cạnh có lẽ không được nhắc đến nhất là ở Việ Nam mình đó chính là tính bảo mật của những csld này, cuối tuần rảnh rỗi sinh nông nổi mình quyết định viết một bài để đánh giá tính bảo mật của csld NoSQL.

Trước khi bắt đầu để tránh gạch đá mình xin làm rõ một vắn để là bản thân CSLD chỉ là: "một tập hợp thông tin có cấu trúc. Tuy nhiên, thuật ngữ này thường dùng trong công nghệ thông tin và nó thường được hiểu rõ hơn dưới dạng một tập hợp liên kết các dữ liệu, thường đủ lớn để lưu trên một thiết bị lưu trữ như đĩa hay băng. Dữ liệu này được duy trì dưới dạng một tập hợp các tập tin trong hệ điều hành hay được lưu trữ trong các hệ quản trị cơ sở dữ liệu." vậy nên nếu vọi vàng đánh giá csld này an toàn csld kia không an toàn chưa hẳn đã chính xác mà một nhân tố vô cùng quan trọng nữa là hện quản trị CSDL (HQTCSDL) ta sử dụng cũng như driver mà ta sử dụng để giao tiếp với HQTCSDL, nội bài biết này mình sẽ giới thiệu một bài lỗ hổng thường gặp trong các HQTCSDL NoSQL., mà cụ thể là MongoDb HQTCCSDL NoSQL phổ biến nhất hiện nay.

Cơ Chế Hoạt Động

Ngay trên trang MongoDB Developer FAQ có nói:

"... with MongoDB we are not building queries from strings, so traditional SQL injection attacks are not a problem."

tức là MongoDb có thể tránh được tất cả các loại SQL injection truyển thống, thay vào đó các hacker lại sự dụng một ký thuật đặc thù cho NoSql đó là NoSQL Injection.

cũng như SQL injection để có thể thực hiện NoSQL Injection hacker cũng phải truy vấn lên server, dựa vào request từ client server sẽ truy vấn đến Database và nhận lại kết quả từ database để trả cho client. Nhiệm vụ của hacker là phải làm sao để hiểu sai request dẫn đến thực hiện một câu truy vấn không mong muốn đến database cuối cùng hacker sẽ lấy được thông tin mong mốn hoặc ngiêm trọng hơn là tthay đổi thậm chí là xóa dự liệu trong csdl.

điểm khác của NoSQL Injection so với SQL Injection truyển thống là:

• câu truy vấn cho khối dữ liệu không cấu trúc.
• các HQTCSDL rất đa dạng và khác biệ nhau khá nhiều trong cachs tổ chức dữ liệu cũng như truy vấn.
• cho phép truy cập trực tiếp client-database thông qua RESTfull API.

Các Loại Tấn Công

có 3 loại tấn công **NoSQL Injection chủ yêu là:

• Login bypass for MongoDB on PHP and NodeJS
• String concatenation
• Escaping flaws of drivers

1. LOGIN BYPASS

đây là loại tấn công rất nguy hiểm vì hacker có thể bỏ qua quy trình đăng nhập và giành quên một cách không mất khó khăn.

giả sử ta có một đoạn login sử dụng NodeJs - express.js - mongodb như sau:

// NodeJS with Express.js
db.collection('users').find({
"user": req.query.user,
"password": req.query.password
});

ở đây ta sử dụng luôn tham số trong request của client để thuwchj hiện câu truy vấn đên database. với dự đoán than số mà người dùng gửi lên sẽ dạng như này:

✔ https://example.org/login?user=patrick&password=1234
trong trường hợp này nếu ông hacker vui tính nào đó gửi lên một request dang như này thì chuyện gì sẽ sảy ra:
⚡ https://example.org/login?user=patrick&password[%24ne]=

khi đó câu query của chúng ta sẽ như thế này

// NodeJS with Express.js
db.collection('users').find({
"user": "patrick",
"password": {"&ne": ""}
});

serlector &ne (not equals) sẽ tìm những bản gì khong bằng giá trị "" tức là trường password sẽ luôn luôn true, hacker đã by pass thanh công.

2. String Concat

Tương tự như SQL Injection vấn đề nối chuỗi (string concat) vẫn là một vấn đề, nếu dev code cẩu thả thì hacker có thể lợi dụng để injectect những đoạn ký tự đặc biệt làm câu query bị thực thui sai mục địch.

vẫn là chức năng đăng nhập trên làn này ta chọn một cách cài đặt khác như sau:

// nodejs example
var string query = “{ username: ‘“ + user + “’, password: ‘” + password + “’ }”

một đoạn có trông có vẻ ngây thơ vô tội nhỉ? nhưng với hacker thì đây đúng là một cơ hội vàng.

⚡ https://example.org/login?username=admin’, $or: [ {}, { ‘a’:’a&password=’ } ], $comment:’hacked’

với request trên câu query của chúng ta sẽ biến thành thế này:

{ username: ‘tolkien’ , $or: [ {}, { ‘a’: ‘a’, password: ‘’ } ], $comment: ‘hacked’ }

OMG, một lần nữa chúng ta đã bypass được login với biểu thức toán tử $or : [true, false ] sex trar laij keets quar true :D

Ngoài ra còn khá nhiều kỹ thuật tấn công khác nếu hứng thú anh em có thể hỏi bác gut gồ nhé.

Read More

[JAVASCRIPT] JavaScript hoạt động như thế nào?

1. Single Thread

1. Làm một việc tại một thời điểm Không giống như đa số các ngôn ngữ lập trình khác, javascript đơn giản là đơn luồng. Điều này đồng nghĩa với việc tại một thời điểm nó chỉ xử lý duy nhất một việc. Bất cứ tác vụ nào đều phải thực hiện lần lượt, khi một tác vụ của bạn thực hiện quá lâu cũng tương ứng với việc trình duyệt sẽ chờ xử lý tác vụ đó xong mới thực thi các tác vụ tiếp.
2. Mỗi tab hold một single thread Môi khi bạn mở thêm một tab mới trên trình duyệt, trình duyệt sẽ sinh ra một javascript single thread. các thread giữa các tab độc lập với nhau về logic xử lý. # 2. Heap And Stack
   
   Mỗi Single Thread javascript sẽ có một bộ nhớ heap và stack. Giống đại đa số các ngôn ngư lập trình khác, heap là nơi lưu trữ các dạng dữ liệu về object, còn stack là nơi lưu trữ dữ liệu trong quá trình thực thi code. Stack của javascript là một dạng LIFO data storage, nôm na có thể hiểu là nơi lưu trữ các hàm hay câu lệnh nào đang được thực thi. Các lệnh sẽ được push vào theo thứ tự vào sau cùng ra đầu tiền. NHững cái ô vàng vàng mà các bạn nhìn thấy trong hình vẽ được gọi là một stack frame. Nếu bất kì lời gọi nào tại frame hiện tại bị lỗi, javascript print stack trace ra console log của trình duyệt. function baz(){ throw new Error('Something went wrong.'); } function bar() { baz(); } function foo() { bar(); } foo();

3. Eventloop and callback queue

Eventloop và callback queue là 2 component khá thú vị của javascript.

Hãy hiểu đơn giản thế này, Bây giờ bạn có một tác vụ, đó là gửi một http-request để lấy thông tin từ một trang web nào đó chẳng hạn, và tác vụ này cần một thời gian dài cơ 1 phút để xử lý. Nếu như trình duyệt sử dụng cùng một thread xử lý javascript cho việc xử lý các tác vụ mang tính delay trên thì sẽ ảnh hưởng đến trải nghiệm người dùng vì họ phải đợi 1 phút để có thể tiếp tục sử dụng. Để tránh việc này, với những tác vụ mang tính delay, tức là đòi hỏi thời gian dài để xử lý, trình duyệt đã viết riêng các đoạn code xử lý đống ấy bằng một ngôn ngữ khác và cung cấp cho bạn api để gọi cái đống phức tạp ấy một cách rất sáng sủa. Ví dụ, setTimeout, setInterval, các tác vụ liên quan đến httpRequest v.v...
Đồng thời trong javascript runtime sẽ sinh ra thêm 2 component là eventloop và callback queue.

Callback queue ở đây là một queue chứa các hàm callback- thứ mà được ném vào cùng với lời gọi các api phức tạp ở trên.
Ví dụ:

setTimeout(function (){
console.log("this function is callback");
},3000);

Ở ví dụ trên cái funtion bên trong được gọi là callback, khi lời gọi hàm setTimeout được thì xong, thì hàm callback kia sẽ được đẩy vào callbackqueue.

Eventloop là thằng luôn luôn lắng nghe cái callback queue kia xem có thằng nào xuất hiện không thì bên nhấc nó ra thực thi lần lượt. Ở đây khi hàm callback được push vào callback queue thì thằng eventloop đang làm nhiệm vụ lắng nghe bống thấy một ông callback funtion được push vào, ngay lập tức, nó bê cái funtion callback đó ra stack để thực thi, và tiếp tục nhiệm vụ lắng nghe của mình.

Như vậy, về cơ bản, những component giúp javascript hoạt động m đã liệt kê ở trên

Read More