Same Origin Policy (SOP) preserves the data of other domains...
There are two parts to the SOP:
- It prevents scripts on origin A from reading data from origin B.
- It prevents sites on origin A from sending anything but so called "simple" requests to origin B. Simple requests are limited to GET and POST, and only a few headers can be modified.
...and therefore nulls out the use of CSRF.
The SOP does not protect against CSRF. Why?
- A CSRF attack is done by sending a request, and not by reading anything from the response. In fact, you neither can nor need to read the response.
- You would normally use simple requests in a CSRF attack.
As you can see, the limitations mentioned above that the SOP puts in place does not prevent CSRF attacks.
Now considering the Same Origin Policy only applies to XMLHTTPRequest...
No, it does not. It applies to all data a browser handles. Whether you use an XMLHTTPRequest, an ordinary form, or the fetch API is irrelevant. The same restrictions apply.
...so with a cleverly crafted form, I can do a POST request witch voids the SOP and hence the need for CSRF tokens.
With a cleverly crafted form, you can make a POST request that executes a CSRF attack, yes. And that is why you need special protection, such as CSRF tokens.
Now with all of this, does the CSRF kind of work around the SOP or works through it?
I'm not sure what "working around" or "working through" the SOP would mean. Instead, let me say this: CSRF is possible because browsers let you send cross origin POST requests.