Mua sắm vui blog

Tác hại của việc đi xem bói

Thực sự ra là tôi vừa tranh cãi với một nhỏ trong công ty . Vì khách hàng đã xem bói ngày thành lập công ty nên đã xảy ra khó khăn cho việc tư vấn . Haixxx ! Bản thân mình còn không tin nói gì tin mấy ông già nói chảm để lấy tiền thiên hạ !

Nguyên Nhân:

Chẳng biết ! nhưng xã hội ngày càng thiếu tự tin thì phải ! hoặc dân giàu sợ chết hơn dân nghèo thì phải ! Giàu sang sinh lễ nghĩa mà.

Riêng tôi ! tôi đặt niềm tin vào cái nào đó thôi! còn phần lớn là do tôi quyết định chứ không thể để mấy ông xem bói phán sét được . Xem bói ra ma ! thế nên kiêng xem bói cũng là một cách làm cho cái tinh thần của mình trở nên thanh thản.

Dịch vụ thành lập công ty

Dịch vụ thành lập công ty của Việt Tín law - Việt Tín là một trong những nhà tư vấn đăng ký kinh doanh và thành lập công ty tốt nhất, với uy tín nhiều năm của mình, Việt Tín cam kết giúp bạn thành lập công ty nhanh nhất và rẻ nhất có thể, cảm thấy hấp dẫn ? Chúng tôi còn cung cấp miễn phí gói dịch vụ tư vấn kế toán thuế và pháp lý trong thời gian công ty bạn hoạt động trong vòng một năm.

Thủ tục cần chuẩn bị ? Bạn chỉ cần CMT nhân dân bản sao y, còn lại gồm thủ tục hồ sơ và nộp cơ quan chức năng, khắc dấu ... đều do chúng tôi thay mặt bạn làm việc, bạn chỉ cần lo lắng cho những bản kế hoạch kinh doanh sắp tới của mình.

Chúng tôi có phần hỏi đáp doanh nghiệp, nếu bạn còn bất cứ thắc mắc nào có thể click vào đây để được trợ giúp ngay tức khắc ...

Liên hệ ngay tới đường dây nóng của Việt Tín để được tư vấn thêm bạn nhé !

Liên quan đến dịch vụ thành lập công ty:
Hướng dẫn chi tiết các bước thành lập công ty
Quy tắc đặt tên công ty

Phát hiện thú vị

Một trong những thứ thú vị nhất ngày hôm nay đó là :
Sau khi kiểm tra các blog mình làm từ hai năm trước đột ngột các blog lên PR = 1 ! oạch ! vui quá đi ! không hiểu google nữa ! những nỗ lực được trả giá bằng sự im lặng còn sự im lặng được trả giá bằng thành quả !

Vui ! vui !

Mỗi ngày đều như thế

+ Mỗi ngày bơi qua dòng đời 120 000 m để đến chỗ làm và bơi qua dòng đời ấy 6 Km trở về

+ Mỗi ngày vượt qua 6 ngã tư và bằng ấy đèn đỏ đi làm.

+ Mỗi ngày vẫn cái quán ăn ấy : 20 ngàn cô ơi

+ Ngày nào cũng gương mặt ấy ! bằng ấy người

Update wordpress lỗi - show ra trang trắng ?

Đang update thì báo lỗi ! bấm nút back quay lại thì thôi rồi ! trắng te luôn , nếu bạn nào gặp lỗi tương tự mình chỉ cho :

Cách duy nhất:
1.log vào FTP
2. Tải bản đầy đủ mới nhất
3.Ném hết chúng vào core và cho phép ghi đè
4. Xong ! đánh vào address .../wp-admin/upgrade.php cho chạy phần còn lại
5. XONG ! hết lỗi, nếu bạn còn lỗi làm tiếp như sau:

a. Rename folder plugin.
b. log vào admin và ftp,
c. quẳng từng cái vào folder plugin , refresh trang admin đến khi nào bị lỗi, dừng lại plugin đó và xóa nó đi !
d. Nếu vẫn bị : call me !

Null vs Empty (Zero Length) stringNull vs Empty (Zero Length) string

Not many end users understand the difference between an empty string of zero length (”) vs Null. We have seen that at times, the end users put in an empty string in a field and there are no checks in the system to prevent them from being able to get that data into the database. An empty string of zero length is not the same as a Null value in SQL Server. A string of zero length is still a string with no characters – a Null on the other hand can mean more than just denoting an absence of data. Maybe the data is not applicable or the data is missing or it is just not present yet. A classic analogy given in this case is that of a blank CD with nothing on it vs no CD. A lot of debate is there about the usefulness of Null and the design patterns but that is not what we want to cover here today. We will provide some links in the Resources section which cover that topic as well. What we want to mention in this post today are the differences between a Null value vs a zero length string and how the behavior is also different between different RDBMS. We will cover this for a couple of different data types besides the string data type.

We have blogged about the side effects of using a zero length string for an integer data type column before – here. Today, we saw a similar issue at a client site – this time with a datetime data type column. Here is an example (using SQL Server here):

declare @table table (col1 datetime)

insert into @table values ('');

select * from @table

———————–
1900-01-01 00:00:00.000

The empty string gets converted to the default datetime value of 1900-01-01 00:00:00.000 as shown above. Not really what the end user was expecting. And why do we get that particular date? Because datetime is internally stored as two integers (hence the 8 bytes per datetime value) – the first integer stores the number for computing dates before or after the base date of 1900-01-01 and the second integer has the number of clock ticks post midnight with each tick being 1/300th of a second.

So, what could be some other issues that this can result into besides silently corrupting the data?

a) Your SQL code that would otherwise expect to work like the IS NULL or IS NOT NULL checks won’t work anymore,
b) In case you were doing this for a number column, the aggregate functions like AVG() which otherwise would be ignoring the Null value will now count the record,
c) The SQL code which uses functions like ISNULL(), COALESCE() etc. will not function as expected since these fields will not have a Null value.
d) The sorts won’t work as expected since Null and the empty string (and the subsequent default value that actually gets inserted) are not the same thing.
e) If you have this column as part of the foreign key, you will get an error at the time of the insert itself since instead of a Null value, the code will try to insert another default value in and it will violate the FK constraint.
f) Any concatenation operations or MAX(), MIN() functions can lead to un-desired results.

As always, there is no substitute for good design and good code. A good design can put checks in place both at the application level (validations – either at the client side or application layer) as well as the DB level (check constraint) to prevent such scenarios from happening.

Do note that if you enter in an empty string of more than zero length, in SQL Server, the result would be the same. ANSI_PADDING does effect the storage but the comparison rules remain the same. You can read more on that in one of our previous blog posts here.

And if we were to use a varchar or a char column, the behavior is the same with the difference of course being that it is string of length 1 in the case of a CHAR data-type column.

declare @table table (col1 char(1), col2 varchar(1))

insert into @table values ('', '');

select col1, datalength(col1) char_str_length, col2, datalength(col2) varchar_str_length from @table where col1 = ''

col1 char_str_length col2 varchar_str_length
---- --------------- ---- ------------------
     1                    0

Also, if you are a developer who has worked in both SQL Server and Oracle, then you would know that the behavior in Oracle is a bit different. It treats Null and an empty string of zero length, the same way. And it treats an empty string of more than a zero length different than a Null value. This is different than the ANSI (and SQL Server behavior). So, in Oracle:

a) A zero length variable length string (varchar2 data type) is treated as a NULL.
b) A string of more than zero length is not treated as a NULL.
c) A zero length fixed length string (char data type) is not treated as a NULL since CHAR data types are blank padded strings.

Here is an example:

SQL> select 1 as col1,length('') LEN from dual where '' is null

col1 LEN
———- ———-
1 NULL

SQL> select 1 as col1,length('') LEN from dual where to_char('') is null

col1 LEN
———- ———-
1 NULL

This shows that an empty string is treated as a null in Oracle and the default data type of an empty string is varchar2 since if it were char, then automatically its length would have been one as stated above.

It is always better to check for such issues and in order to follow the same guidelines across RDBMS, check for empty strings via client side logic or application layer logic or check constraints at the DB level and ensure that you are going to put in NULL if that is what your design intention was rather than having such side effects of the empty string.

LOcal attack và cách tấn công !

Local Attack là một trong nhưng phương thức hack không được khuyên dùng vì lý do đạo đức. Tuy nhiên tìm hiểu và đề phòng local attack lại là một chuyện thú vị rất được quan tâm.

Define:

Đối với một web server thông thường.

Khi các bạn host site của mình trên server, thông thường bạn được cấp 1 account trên server đó và một thư mục để quản lý sai của mình. Ví dụ là /user/username1. Tương tự như vậy cũng có 1 thư mục là /user/username2. Giả sử /user/username2 bị hacker chiếm giữ, bằng các script thông thường, hacker có thể truy cập đến các file của bạn ở /user/username1. Các tấn công dựa trên những script ở user này tấn công vào host của user khác trên cùng server gọi là Local Attack.

Thông thường nhất, Local Attack được sử dụng để đọc lấy thông tin config từ victim, sau đó dựa vào thông tin config này để phá hoại website.

Từ phương thức của Local Attack, cách phòng chống Local Attack chủ yếu dựa trên 3 mục:

Config của server: cấu hình server của super admin, tùy vào cách cấu hình mà khả năng tránh local attack sẽ tăng or giảm

Source code của website: thường các website khi chạy trên mạng không dc zend ( encode php ) hoặc mã hóa. Khi đó local attack sẽ dễ dàng hơn. Ngoài ra tùy vào source của từng website và tùy chỉnh của developer mà có thể hoặc không thể tránh local attack.

Chương trình bảo vệ trên server: những chương trình như NAV hoặc KPS có thể chặn được những scrip độc hại -> disable local attack

Nói sơ qua về cách tấn công: như đã nói trong phương thức, chủ yếu là hacker phải đọc được config của website để tiến hành cách bước tiếp theo ( :”> ). Việc xác định file config nằm ở đâu và làm thế nào để đọc được nó đòi hỏi cả trình độ lẫn kinh nghiệm. Sau khi xác định được file config, hacker sẽ sử dụng các lệnh khác nhau để cố gắng lấy nội dung của file nay. Ở đây đưa một số ví dụ về vài vị trí file config

VBB: <root>/includes/config.php
Joomla <root>/configuration.php

Có nhiều cách tấn công vòng vèo nhằm qua mặt cơ chế bảo mật của server, song đều qua các bước tương tự như sau:
Bước 1: Tấn công site bị lỗi bảo mật nằm cùng server với website cần tấn công thông qua các bug và upload Shell nên website này. có rất nhiều loại shell cho 1 và nhiều ngôn ngữ như : php shell , asp shell, aspx shell, jps shell...tùy thuộc vào server hỗ trợ loại ngôn ngữ nào và đôi khi là sự kết hợp nhiều shell trong lúc tấn công .
khi upload lên ta có dạng: http://a.com/shell.php và con shell này đã nằm cùng server với website cần tấn công b.com
Bước 2: tấn công.Tại Shell Command ta bắt đầu gõ lệnh:

1.cat /etc/passwd

sẽ cho ra được kết quả nhiều dòng dạn như sau:

1.tphats:33217:33218::/home/tphats:/usr/local/cpanel/bin/noshell

bạn thấy user chính là tphats. tiếp theo bạn kiểm tra domain của site cần tấn công.

1.cat /etc/userdomains

nhìn kết quả thấy user domain
vậy là đúng tphats là user của tanphat.net
tiếp tục dùng lệnh để xem trong thử mục www của tanphat.net có những file gì?

1.dir /home/<strong>tphats</strong>/public_html/

ta có 1 list file và thư mục:

admin
include
image
template
index.php
config.php
footer.php

để đọc file để xem file nào chứa liên kết với database. nhìn vào đây đích thị là config.php. ta đọc fie này thử:

cat / home/tphats/public_html/config.php
{code}
ta thấy kết quả như sau:
{code}

Như vậy đã đã có được user + pass của mysql, công việc còn lại của bạn là gì? kết nối data update user + pass và bắt đầu đăng nhập: http://tanphat.net/admin

bài viết này được mô phòng trên môi trường linux với việc config server yếu. Thức tế không dễ dàng như vậy, có những website không cho upload file php, asp... thông qua browse hay khi upload lên thành công thì anti virus của server xóa mất. vì vậy các hacker thương link đông trong tấn công. Ví dụ: zend code , hay base64 code shell để server không phát hiện. nếu khóa hàm cat thì chạy hàm read, less...
………….

Nói về vài cách mà tôi biết:

Về server: Jail Apache : từ host của user này không thể truy cập tới file ở host của user khác
Về web source code: Zend -> encode source để hacker ko thể đọc được nội dung dù đã tìm ra file, chmod file để ko thể đọc từ bên ngoài …
Về security app: NAV -> tắt dc nhưng script như Shell r57 r59 …

Nhìn chung, đối với tất cả các website thì local attack là ác mộng vì gần như nếu bị local attack thì sẽ die trong nháy mắt. Tuy nhiên những hacker thực sự sẽ không sử dụng cách này trừ khi bị khiêu khích. Cho nên nếu bạn là web master, hãy ngoan ngoãn và đề phòng. Nếu bạn là server admin, phải bảo vệ cho người dùng. Nếu bạn là hacker, làm ơn đừng sử dụng cách này. Còn nếu bạn như tui nghĩ, không cần lo nhiều về nó.

Như đã nói, local attack là tấn công từ user cùng server với nhau. Vậy làm sao có thể sử dụng một user này để tấn công một user khác? Thông thường có 2 cách:
1. Cách này tốn khá nhiều thứ quý giá : tiền. Lấy tiền mua một cái host trên server đó rồi local -> chắc 100% thành công.
2. Tấn công vào website cùng server có độ bảo mật thấp hơn. Sau đó local.
Thông thường hacker sử dụng cách thứ 2, chắc ai cũng hiểu lý do. Vậy làm sao để tấn công vào những mục tiêu bên cạnh? Có mấy bước sau:
1. Tìm xem trên server có những website nào? Cách hiện tại được dùng nhiều nhất là Reverse IP domain đó. Hiện tại có khá nhiều website cung cấp dịch vụ này.
2. Sau khi tìm được danh sách website, lần lượt check xem website nào có khả năng tấn công thành công và có thể sử dụng local.
3. TIếp theo đó tấn công website đã chọn.
4. Sau khi attack thành công, bắt đầu local attack.
5. Local attack thành công hay thất bại còn là chuyện sau này.
Quan trọng nhất ở 5 bước này là tìm xem website nào có độ bảo mật kém hơn và có thể bị hack. Thường nhưng website như thế là:
1. Những website tự làm, khả năng mắc lỗi thường cao.
2. Những source code phổ thông nhưng version đã lỗi thời.
Nếu tìm thấy trường hợp số 1, từ từ check lỗi và hack.
Nếu tìm thấy trường hợp số 2, có thể check xem version hiện tại có lõi gì không tại trang web milw0rm.com
Từ đó, các bạn có thể thấy ra được khi nào mình xài local. Đó là những website có độ bảo mật cao, không thể tấn công qua lỗi lập trình, đồng thời server config khá an toàn không thể tấn công chiếm root, bắt buộc phải local.. Những website như thế thường là những website được update thường xuyên nếu như là cái source thông dụng hoặc những website với coder pro :D.
Nói từ đầu tới h, chắc các bạn cũng nhận ra dù muốn hay không, nếu không thể chiếm server bằng cách này hay cách khác, hacker vẫn bị bắt buộc phải tấn công trực tiếp thành công một website khác. Nói như vậy, nghĩa là muốn local, hacker phải luyện mấy cái khác trước đã. Vì quan điểm này cho nên trong một số trường hợp, có thể sử dụng local :D.
Nghĩ đến chuyện tấn công trực tiếp một website nào đó với mục đích up shell / local, hacker phải lợi dụng những lỗi/lỗ hổng để can thiệp vào cấu trúc của website. Nếu các bạn đã biết, có những lỗi cực ký cơ bản mà ai tham gia security zone đều biết như:
1.Lỗi Sql Injection
2.Lỗi XSS
3.Lỗi zero-length string (có cả chuyên gia chuyên khai thác lỗi này luôn nè). -> bữa trc Joomla bị lỗi này nè.
4. và còn nhiều nhiều nữa… mà tui hok biết.
Mỗi lỗi có mức độ nguy hiểm , cách kiểm tra, và cả cách phòng chống khác nhau. Còn hacker làm sao biết nên khai thác lỗi nào, câu trả lời chỉ có thể là từ kinh nghiệm -> test các lỗi xem dính cái nào thì làm việc với cái ấy thôi…..
Nhìn chung, muốn tấn công những website dạng như vbb thuần hoặc joomla thuần hay đại loại giống vậy, cách duy nhất là local :D. Có vài hacker tự nhận mình là Hacker Mũ Bạc (đẹp), để thoát ra cái vòng trắng đen nhưng thực chất đó chỉnh là hacker mũ xám

hay thậm chí có khi tệ hơn là script kiddies giả danh, sử dụng những chiêu local thế này để nổi danh. Thực chất không đáng nói lắm.
Bài viết này chỉ nhằm dẫn người đọc đến con đường chính đạo mà thôi.

(BÀI VIẾT ĐƯỢC SƯU TẦM)

Trang