You say "session" - do you have a server-side session? If so, why not put the CSRF token in the session instead of a client-side cookie? That's the normal pattern; it prevents an attacker being able to use their own generated CSRF token value against another user in the case where they have cookie fixation.
Another similarly watertight approach not needing an extra cookie, if you don't have server-side storage, is to create a value including the user or session ID and sign it using a MAC (typically HMAC) with a server-side secret. The server can then verify that the token in the form came from the user whose session it is.
attacker can't read or set the cookie of a domain that he doesn't own
Well, probably... usually. Ways that cookie injection tends to happen (other than XSS in which case you already lost much worse):
- browser bugs, outdated "generic domain" tables/rules etc
- vulnerable neighbour domains (eg set cookie on www.example.com from test.example.com)
- allowing your site to be served from an attacker domain (always check the Hostname: is a recognised-good domain name)
These are typically marginal issues but they depend on factors potentially outside your control as an application author. So for security-sensitive systems it's generally a good idea not to rely on your cookies being unfixatable.