CEH: SQL Injection

1. Từ khóa tìn kiếm site bị lỗi 
- index.php?id=
- news.php?id=
- article.php?id=
- games.php?id=
- pages.php?id=
- view.php?id=
- opinions.php?id=
- ....
2. Các bước tấn công sử dụng lệnh union, select
- Kiểm tra lỗi sql injection.
- Tìm số cột mà câu truy vấn tạo ra
- Tìm cột chứa thông tin có thể khai thác được.
- Xem phiên bản của CSDL và ngôn ngữ lập trình.
- Xác định tên bảng chứa thông tin người quản trị
- Xác định tài khoản / mật khẩu của quản trị.
- Truy cập vào phần giành cho quản trị.

F5 big-ip: Web Acceleration profile

Topic

This article applies to BIG-IP 11.x. For information about other versions, refer to the following articles:

• SOL13244: Overview of the RAM Cache feature (10.x)
• SOL13245: Overview of the RAM Cache feature (9.x)

HTTP caching allows a cache-aware system to store frequently-requested web objects in memory for reuse by subsequent connections. This operation is designed to save bandwidth and reduce the amount of traffic load on the origin web servers. The Web Acceleration profile provides settings to configure caching for the BIG-IP system. Associating a Web Acceleration profile with a virtual server allows the BIG-IP system to store HTTP objects in memory and reuse these objects for subsequent connections.

Description

The BIG-IP system includes the HTTP caching feature. An HTTP cache is a collection of HTTP objects stored in the BIG-IP systems memory that subsequent connections can reuse to reduce traffic load on the origin web servers. The goal of caching is to reduce the need to send frequent requests for the same object, and eliminate the need to send full responses in many cases. You can enable HTTP caching on the BIG-IP system by associating a Web Acceleration profile with a virtual server.

Cacheable content

The BIG-IP cache feature complies with the cache specifications described in RFC 2616. You can configure the BIG-IP system to cache the following content types:

• 200, 203, 206, 300, 301, and 410 HTTP responses
• Responses to HTTP GET requests
• Other HTTP methods for Uniform Resource Identifiers (URIs) specified for inclusion in cached content, or specified in an iRule
• Content based on the User-Agent and Accept-Encoding values. The cache feature holds different content for Vary headers.

The default cache configuration caches only responses to HTTP GET requests. However, you can configure the Web Acceleration profile to cache other requests, including non-HTTP requests. To do this, you can specify a URI in the URI Include or Pin List within an HTTP profile, or write an iRule.

Non-cacheable content

The cache feature does not cache the following items:

• Private data specified by cache control headers
• Action-oriented HTTP methods such as HEAD, PUT, DELETE, TRACE, and CONNECT

Settings and definitions in the Web Acceleration profile

The following table contains the settings and definitions for the Web Acceleration profile:

Setting	Value	Description
Cache Size	100 MB	Specifies the amount of memory the system provides for caching per TMM. The total cache size equals the Cache Size multiplied by the number of TMMs on the system.
Maximum Entries	10000	Specifies the maximum number of entries the system allows for caching.
Maximum Age	3600 seconds	Specifies the duration in which the system considers the cached content valid.
Minimum Object Size	500 bytes	Specifies the minimum object size, in bytes, that the system stores in the cache.
Maximum Object Size	50000 bytes	Specifies the maximum object size, in bytes, that the system stores in the cache.
URI Caching	URI List...	Specifies the Uniform Resource Identifiers (URIs) that the system retains or excludes in the cache. The pinning process forces the system either to retain URIs in the cache indefinitely, cache URIs that typically are ineligible for caching, or to not cache URIs that typically are eligible for caching.
URI List	Pin List - Lists the URIs for responses that you want the system to store indefinitely in the RAM cache. Include List - Lists the URIs that are normally ineligible for caching, but the system caches them. When you add URIs to the Include List, the system caches the GET methods and other methods, including non-HTTP methods. Exclude List - Lists the URIs that are typically eligible for caching, but the system does not cache them. Include Override List - Configures a list of URIs that should be cached, even though they would normally not be cached due to constraints defined by the Maximum Object Size setting or other settings. The default value is None. URIs in the Include Override List are cacheable even if they are not in the Include list.	The URI list specifies the URIs that you want to cache or exclude from the cache.
Ignore Headers	All - The system disregards all Cache-Control headers in request headers. Cache-Control:max-age - The system disregards any Cache-Control:max-age request header that has a value of max-age=0. None - The system processes all Cache-Control headers in request headers.	Specifies how the system processes Cache-Control headers.
Insert Age Header	Enabled	Specifies whether the system inserts Date and Age headers in the cached entry; the Date header contains the current date and time on the system, while the Age header contains the length of time the content has been in the cache.
Aging Rate	9	Specifies how quickly the system ages a cache entry. The aging rate ranges from 0 (slowest aging) to 10 (fastest aging).

Recommendations

When you configure the Web Acceleration profile for a virtual server, you should consider the following factors:

• Caching is useful for frequently-requested content; for example, caching can be used if the site has periods of high demand for specific content. When you configure a Web Acceleration profile for a virtual server, the content server only has to serve the content to the BIG-IP system once per expiration period.
• Caching is useful if a site contains a large amount of static content such as CSS files, JavaScript files, or images.
• For compressible data, the cache feature can store data for clients that accept compressed data. When used with the compression feature on the BIG-IP system, the cache takes stress off of the BIG-IP system and the content servers.
• Tham Khảo: https://support.f5.com

F5 big-ip: OneConnect Profile

1. Tổng quan
 - Chức năng của OneConnect trên hệ thống Big-ip là tăng thông lượng mạng bằng cách quản lý hiệu quả các kết nối tạo ra giữa hệ thống Big-Ip và các server backend. OneConnect làm việc dựa trên keep-alive để cho phép Big-ip giảm thiểu các kết nối TCP connect(vi mỗi request của client sẽ tạo ra connection: close  ==>sẽ tăng số kết nối TCP connect (tham khảo bài viết giao thức HTTP)).
 - Ví dụ: khi 1 client tạo 1 connect tới 1 virtual server Big-Ip đã cấu hình OneConnect profile, hệ thống Big-Ip sẽ phân tích http request, chọn 1 server bằng cách sử dụng giải pháp load-balancing đã định nghĩa trong pool, và tạo connection to server đó. Khi http request đầu tiên của client được hoàn thành thì hệ thống tạm thời giữ connection open và làm cho connect này chờ được tái sử dụng tới pool member đã được chọn.
2. OneConnect và SNATs
 - Khi 1 client tạo 1 connect mới tới VS Big-ip đã cấu hình 1 OneConnect profile và SNAT, hệ thống Big-Ip sẽ kiểm tra http request, chon server sử dụng bẳng  phương pháp load-balancing trong pool, dịch địa chỉ source ip trong request thành  địa chỉ IP SNAT, và tạo kết nối tới server. Khi http request đầu tiên của client được hoàn thành thì hệ thống tạm thời giữ connection open và làm cho connect này chờ được tái sử dụng tới pool member đã được chọn. Khi có 1 kết nối mới được khởi tạo kết nối tới VS, hệ thống Big-ip thực hiện chuyển đổi địa chỉ và sau đó áp OneConnect và xác định xem nó có đủ điều kiện sử dụng connect đang chờ hay ko
3. HTTP considerations
 - Đối với luồng traffic http  đủ điều kiện kết nối với OneConnect, Web server phải hỗ trợ kết nối http keep-alive.
- HTTP/1.1 request: mặc định bật http keep-alive. Với http/1.1 thì server sẽ không đóng connection khi chuyển nội dung hoàn thành. chờ đến khi client gửi connection: close trong header của request hoặc hết thời gian RTT.
- HTTP/1.0 : mặc định ko bật http keep-alive.
-OneConnect Transformations: được cấu hình trong HTTP profile cho phép hệ thống Big-Ip thực hiện biến đổi HTTP header cho mục đích cho phép kết nối HTTP/1.0 được chuyển thành HTTP/1.1 request  ở phía server-side. Hệ thống Big-ip sẽ chuyển đổi Connection: close trong header HTTP/1.0 client-side requset thành X-Cnection: close headers trên server-side, điều này cho phép connection được duy trì.
(*) lời khuyên khi dùng OneConnect profile
1. Khi sử dụng OneConnect để tối ưu HTTP traffic, F5 khuyên rằng nên áp dụng cho HTTP profile đến VS. Điều này cho phép hệ thống Big-Ip quản lý hiệu quả việc duy trì kết nối mà không cần cấu hình gì thêm. Việc áp dụng sai tới 1 HTTP profile dẫn tới kết quả như backend server gửi cho client sẽ bị sai.
2. Tránh sử dụng cho các VS không phải là HTTP như FTP, RTSP. Làm như vậy có thể dẫn tới traffic bị disruption và lỗi session. Đối với trường hợp không phải là HTTP thì nên dùng iRule để quản lý kết nối dạng này.
3. Tránh sử dụng trong trường hợp traffic được mã hóa thông qua VS tới đích mà không qua kiểm soát của big-ip.
==> Cấu hình

Giao thức HTTP

Tổng quan

Hypertext Transfer Protocol (HTTP) là giao thức thuộc lớp ứng dụng web. Sử dụng kết nối TCP cổng 80. HTTP được định nghĩa trong RFC 1945 (HTTP 1.0) và RFC 2616 (HTTP 1.1).

HTTP hoạt động dựa trên mô hình client-server. Trình duyệt client thực hiện yêu cầu, nhận và hiển thị đối tượng web (gồm dữ liệu HTML, hình ảnh JPEG, Java applet, video, âm thanh, …). Trong khi, web server sẽ gửi trả lời khi nhận được yêu cầu từ client.

Hình 1. Mô hình client-server

 Kết nối HTTP

Có hai loại kết nối HTTP là kết nối không bền vững và kết nối bền vững.

Kết nối không bền vững: sau khi, server gửi đi một đối tượng thì kết nối TCP sẽ được đóng. Như vậy, mỗi kết nối TCP chỉ truyền được duy nhất một yêu cầu từ client và nhận lại một thông điệp trả lời từ server.

Kết nối bền vững: server sẽ duy trì kết nối TCP cho việc gửi nhiều đối tượng. Như vậy, sẽ có nhiều yêu cầu từ client được gửi đến server trên cùng một kết nối. Thông thường kết nối TCP này sẽ được đóng lại trong một khoảng thời gian định trước.

Quy trình hoạt động của kết nối HTTP không bền vững:

Hình 2. Quy trình hoạt động kết nối HTTP không bền vững

Hình 2 thể hiện chi tiết các bước hoạt động trong kết  nối HTTP không bền vững giữa HTTP client (Firefox, Chrome,…) và HTTP server (ví dụ www.hutech.edu.vn):

-      Bước 1: client khởi tạo kết nối TCP bằng việc gửi yêu cầu đến server. Server nhận được yêu cầu và chấp nhận kết nối bằng việc gửi trả lời về cho client. Nếu sau khoảng thời gian RTT mà không nhận được trả lời từ phía server thì client sẽ gửi lại yêu cầu.

-      Bước 2: sau khi kết nối được thiết lập, client sẽ gửi thông điệp yêu cầu chứa tên đường dẫn của các đối tượng ( ví dụ: www.hutech.edu.vn/homepage/index.php) đến server. Server nhận được thông điệp yêu cầu và tiến hành lấy ra các đối tượng được yêu cầu. Sau đó, các đối tượng được đóng gói thành thông điệp trả lời và gửi đến client.

-      Bước 3: server đóng kết nối TCP (Lưu ý: server chỉ đóng kết nối TCP khi chắc chắn rằng client nhận được thông điệp trả lời)

-      Bước 4: client nhận thông điệp trả lời chứa tập tin HTML và hiển thị các đối tượng.

-      Bước 5: lặp lại các bước từ 1-4 cho các đối tượng khác.

* Lưu ý: Trong kết nối HTTP không bền vững cần có một RTT (Round Trip Time) để khởi tạo kết nối TCP. Ngoài ra, cần có một RTT cho thông điệp HTTP yêu cầu và một vài byte đầu tiên của thông điệp HTTP  trả lời được trả về.Tổng thời gian truyền tập tin = 2RTT+ thời gian truyền.

Thời gian đáp ứng RTT làthời gian gửi một gói tin cơ bản từ client đến server rồi quay ngược lại. RTTbao gồmđộ trễtruyền gói tin và hàng đợi, độ trễtrongcác bộ định tuyếntrung gian, chuyển mạch vàxử lýgói tin.

Qui trình hoạt động của kết nối HTTP bền vững:

-    Kết nối bền vững không có pipelining:

•     Client phát ra yêu cầu mới, chỉ khi đáp ứng trước đó đã nhận xong.
•     RTT cho mỗi đối tượng tham chiếu.

-       Kết nối bền vững có pipelining:

•       Mặc định có trong HTTP/1.1.
•     Client gửi yêu cầu ngay sau khi gặp một đối tượng tham chiếu.
•       Ít nhất 1 RTT cho tất cả đối tượng tham chiếu.

Thông điệp HTTP

Thông điệp HTTP được viết bằng văn bản ASCII thông thường, do vậy người dùng có thể đọc được. Có 2 dạng thông điệp HTTP: thông điệp HTTP yêu cầu và thông điệp HTTP trả lời.

Thông điệp HTTP yêu cầu:

Hình 3. Cấu trúc chung của thông điệp HTTP yêu cầu

-    Request line: dòng đầu tiên của thông điệp HTTP yêu cầu. Request line bao gồm có 3 trường như: cách thức (method), URL, phiên bản (version). Trường cách thức (method) có thể chứa các giá trị khác nhau, bao gồm GET, POST, HEAD. Phần lớn các thông điệp HTTP yêu cầu điều sử dụng phương thức GET. Các phương thức GET được sử dụng khi trình duyệt yêu cầu một đối tượng được xác định trong trường URL. Phương thức POST là những phương thức mà HTTP client sử dụng khi người dùng điền vào một biểu mẫu (form) nào đó, chẳng hạn như người dung muốn nhập một từ khóa nào đó vào google.com đề tìm kiếm thông tin. Nếu phương thức là POST thì Entity body của thông điệp yêu cầu sẽ chứa thông tin mà người dùng đã điền. Phương thức HEAD tương tự như GET, nhưng Khi server nhận được yêu cầu bằng phương thức HEAD, nó sẽ trả về thông điệp HTTP và không chứa đối tượng được yêu cầu.

-    Header line: là các dòng tiếp theo.

-    Sp: bao gồm các giá trị về khoảng trống.

-    Blank line: bao gồm các giá trị điều khiển trở về đầu dòng, xuống hang (cr,lf).

-    Entity Body (nếu có): là phần thân của thông điệp HTTP yêu cầu.

Sau đây là một ví dụ về thông điệp HTTP yêu cầu:

Hình 4. Ví dụ về thông điệp HTTP yêu cầu

Hình 9.4  giải thích và làm rõ được các thông số sau:

-      GET: Trong ví dụ này, trình duyệt đang yêu cầu các đối tượng /somedir/page.html.

-      Host www.hutech.edu.vn: chỉ địnhcác servermà trên đó cácđối tượng được lưu trữ.

-      Connection: close trình duyệt báo cho máy chủ là nó không muốn sử dụng kết nối liên tục và muốn máy chủ đóng kết nối sau khi gửi các đối tượng được yêu cầu.

-      User-agent : chỉ thị loại trình duyệt gửi yêu cầu đến server, ở đây dùng trình duyệt Mozilla/5.0.

-      Accept-language (fr): chỉ thị người dùng muốn nhận được phiên bản tiếng Pháp của đối tượng chứa trên server, nếu không server sẽ gửi phiên bản mặc định của đối tượng.

Thông điệp HTTP trả lời

Thông điệp HTTP trả lời có ba phần: dòng trạng thái (status line), dòng tiêu đề (header lines), thân thông điệp (entity body). Thân (Body) là thành phần chính của thông điệp. Status line có 3 trường: phiên bản của giao thức (version), mã trạng thái (status code), trạng thái tương ứng (phrase) và các giá trị khoảng trống (sp), điều khiển trở về đầu dòng, xuống hàng (cr,lf).

Hình 5: Cấu trúc chung của một thông điệpHTTP trả lời.

Sau đây là ví dụ về thông điệp HTTP trả lời

Hình 6. Ví dụ thông điệp HTTP trả lời

Trong ví dụ hình 6, cho thấy:

-         Status line thể hiện server đang sử dụng HTTP/1.1.

-          Header line bao gồm:

•      Connection: close báo cho client rằng server sẽ đóng kết kết TCP sau khi gửi thông điệp.
•      Date: cho biết thời gian mà thông điệp HTTP trả lời được tạo và gửi bởi server. Đó là thời gian mà server lấy đối tượng từ hệ thống tập tin của nó, chèn vào thông điệp và gửi cho client.
•      Server: cho biết đây là Apache Web server, tương tự như User-agent trong thông điệp yêu cầu.
•      Last-Modified: cho biết thời gian đối tượng được tạo hay sửa đổi lần cuối.
• Content-Length: cho biết số bytes của đối tượng được gửi.
• Content-Type: cho biết đối tượng trong phần entity body là HTML.

-    Entity body chứa đối tượng yêu trong trường hợp ví dụ trong hình 9.6 được đại diện bởi các data data data data……….

- Mã trạng thái trả lời:

Các giá trị chữ số đầu tiên của mã trang thái (status code) có 5 giá trị:

•       1xx_Thông tin: khôngđược sử dụng, chỉ dự phòngtrong tương lai.
•       2xx_Thành công: hành độngđã nhận đượcthành công và đươc chấp nhận.                                                                                                        
•       3xx_Chuyển hướng: hành động tiếp theo phải được thực hiện để hoàn tất yêu cầu.
•       4xx_Clien lỗi: chứa cú pháp sai có thể không thực hiện được.
•       5xx_ Server lỗi: các máy server không thực hiện một yêu cầu rõ ràng đối với các yêu cầu hợp lệ.

Một vài mã trạng thái thông dụng thường gặp:

•      200 OK: Yêu cầu thành công
•      301 Moved Permanently: đối tượng yêu cầu đã được chuyển.
•      400 Bad Request: server không hiểu được thông điệp yêu cầu.
•      404 Not Found: đối tượng được yêu cầu không có trong server.
•      505 HTTP Version Not Supported: server không hỗ trợ phiên bản giao thức HTTP này.

 Gói tin HTTP

Hình 7. Gói tin HTTP

Hình wireshark trên cho thấyHTTP đang sử dụng phiên bản HTTP 1.1 dùng phương thức GET.

-          Có các mã trạng thái hồi đáp như:

•      200 OK
•      404 Not Found
•      Địa chỉ IP nguồn: 10.0.0.36
•      Địa chỉ IP đích: 192.168.3.35

-          Cổng HTTP: 80

-          Sử dụng phương thức TCP

-    Trang web đăng nhập là (host) http://192.168.3.35 không sử dụng DNS để phân giải địa chỉ IP 192.168.3.35.

-    User-agent: loại trình duyệt gửi yêu cầu đến server ở đây dùng trình duyệt Mozilla/5.0.

-    Accept-language: sử dụng ngôn ngữ tiếng anh (en-us). 

Tham Khảo tại: http://hatangmang.blogspot.com/