Describe the bug vrs serves files that are outside /var/www/static by using .. in path. This allows potentially sensistive files to be read from the server, for example /etc/passwd

To Reproduce

> sudo ./setup.sh
> cargo build
> sudo ./target/debug/vrs &
> echo "GET /../../../etc/passwd HTTP/1.1" | nc localhost 80
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1322

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
vscode:x:1000:1000::/home/vscode:/bin/bash
systemd-timesync:x:101:103:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:104:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:105:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:106::/nonexistent:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin

Expected behavior 404 or 400 error

Type of pull request

This PR makes changes to the test structure and introduces a basic fuzz test harness, as well as fixing a few panics that were tripped while writing the tests.

Overview of pull request

This PR follows through on the majority of https://github.com/PeterPierinakos/vanilla-rustlang-server/issues/5#issuecomment-1164972312. In particular, it moves the integration tests to become unit tests, completely removes the TestServer struct, adds a fuzz harness to detect panics that can be reached from outside, changes the hardcoded buffer sizes to be dynamically sized, and makes a few changes from what I assume to be the correct non-panicking behavior. In particular, I embedded the default media/ error pages into the binary, rather than simply panicking when they are not present- they are still possible to override (though there isn't a test case for that yet.) I decided to remove one of the existing test cases, because I don't think there's anything to do server-side for CORS checks, and I believe it would be easier to remove it than to reimplement the checks (another case where a future test would be good.) The base unit tests now cover roughly 65% of the codebase by the same metric as earlier, almost doubling previous coverage. As far as fuzzing, I ran it for roughly an hour with no crashes, and am currently reasonably confident that it is difficult for external requests to cause a panic at this point. I'm leaving this as separate commits right now to simplify reviewing it in parts, but would be happy to squash the changes into a single commit or multiple smaller commits if desired.

Future possibilities

I did not end up writing any integration tests for this PR. After making the changes I did, I think that going forward, the best course of action would be to move most of the server's unit tests back to being integration tests, but using a third party HTTP client over a socket rather than attempting to create a request by hand. The tests that remain as unit tests should be the ones that e.g. test an empty body and providing broken unicode. I've spent long enough not submitting this PR that I decided to leave it as is, but there are also some additional tests that would be good to write:

• Check for specific headers (i.e. CORS)
• Check that only the configured verbs are accepted
• With a multithreaded server, send two requests, then read them in reverse order (the first shouldn't prevent the second from finishing) If desired, I can redo the hack in the server unit tests to use once_cell, or even just replace it with a static junk path (I don't think it's ever used, so it would be fine to hardcode it to "nonexistent").

What is the feature you want to improve or implement? When looking running an informal audit of this codebase, I noticed there are zero test cases at all. Considering VRS attempts to parse (even a subset of) HTTP on its own, I find this extremely surprising. Ideally, there should be a decent range of request-response pairs, as well as some form of fuzzing to catch parsing errors.

Additional information: As currently structured, I don't think the implementation of the server is particularly testable. It uses a hardcoded address+port (as well as requiring root/admin to run), and there is no other way for code to send the core of the server a request. Reorganizing the server to have some form of fn serve_request(configuration: Configuration, input: impl Read, output: impl Write) (note that this signature is infallible- errors should be written to the output here [HTTP status code] and/or a configured logger) would drastically increase the testability of the server and build confidence in its correctness.

If a refactor that introduces these features occurs, I'm willing to help build a test suite to run on them.

There is a lot of unwraps that should be ?s with error handling, ideally returning appropriate HTTP error status code in server response. The most egregious are unwraps on reading from socket, and on parsing utf8, both are trivially exploitable for DOS attacks:

1. Open a connection, send no data, close connection: read will error, unwrap will panic, server will crash.
2. Send a request with malformed (non-utf8 URI): from_utf8 will error, unwrap will panic, server will crash.

Multi-threading is safer since panics only kill the thread they occur on, but they should still be avoided.

What is the feature you want to improve or implement? Error-handling in the codebase.

Additional information: Currently, the project heavily relies on the excessive usage of unwraps in the main logic of the code. I believe that we could replace all possible panics in the server with more graceful errors and decrease the use of unwraps.

I'm going to implement this change myself, submitting this issue in order to track the changes happening.

This PR cleans up multiple Clippy lints that trigger on the current main branch. One of these lints in particular, clippy::unused_io_amount, can lead to transient errors that fail to write a complete response body and randomly. The remaining lints are for the most part stylistic choices that are considered idiomatic in the Rust world, and/or switching usage of owned types to borrowed types when the owned type isn't needed in function arguments (e.g. String -> &str).

Is your feature request related to a problem? Please describe. No.

Describe the solution you'd like Implement origin blocking via the Cors struct.

Describe alternatives you've considered

Additional context This feature request is open just in case if any new contributor would like to try and implement it. In the meantime, I just implemented an algorithm to find all the headers from a plain String in the utils directory and now I will read more about how CORS works.

What is the feature you want to improve or implement?

It would be nice to implement a way for the host to just be able to write their documents in markdown syntax and when an end user tries to access that document it gets interpreted into HTML before being sent to the browser.

Additional information:

I want to implement this because it's more convenient for some people to write documents in markdown than in HTML.

The way this would work is, for example, the server host creates a helloworld.md file in /var/www/static and when a user tries to access http://localhost:80/helloworld.html the server finds a file with the same name but in the markdown extension (.md), it interprets it to HTML and then it sends back the HTML it generated.

This could add some overhead on the server-side because in the worst case scenario the markdown document could be very large and hundreds of lines, so parsing and interpreting the document before sending it back could take a long time. In the future this could be improved by implementing caching for the documents, but this is only going to be considered if I decide that this idea is worth implementing into the final product.

Would love to hear feedback for this idea from anyone passing by. This is probably going to be considered for v1.2.0.

This PR adds running the Clippy checks to CI and changes the matches! invocations in the unit tests for assert_eq!, causing failing tests to automatically print the expected and received values. On my machine, both Clippy and tests fail, but I think it's worth the time to mark the failures in CI rather than only seeing them locally.

Type of pull request

Code enhancement

Overview of pull request

This PR will replace most .unwrap()s and .expect()s in the code with ? and introduce proper error handling by propagating the errors through the Server's methods and more.