I am developing CSRF protection with a token for one of my applications. Since there is no place to implement the token in POST or GET or form data, I am thinking about putting it in a cookie. Is that a good approach?
Putting the CSRF token in a cookie instead of in a form field or HTTP header is a bad approach, and will not work. The thing that makes the CSRF token effective is that (unlike e.g. a session cookie) it is not sent automatically on all requests. It has to be added manually by your application. If you put it in a cookie, it will be send automatically and thereby it looses it's effect.
Of course, if you are using the double submit cookie pattern you will need a cookie. But that is a different story.
the completely violates the use of having a csrf token.Let me explain why. when ever a victim submits any request his browser automatically submits the cookies associated with that domain.so csrf works because the broken submits the session credentials(if victim is logged in).so if you put anti csrf token then it will be submitted along with it.instead you want to submit the csrf token in a POST request.
No. Not a good approach.
This makes it even more difficult to both ensure that the CSRF is effective and handle a split session (i.e. 2 windows). Further the cookie persists independently of the navigation path (i.e. does not provide proof of the origin for the request).
I am very confused by your assertion that there is "no place to implement the token in POST or GET or form data" but you seem to have the required access to control what cookies are deployed by the application.
The problem with cookies is that they tend to overwrite each other, and further, they can be shared between multiple tabs/windows in the same browser. So, for example, a (poorly designed) CSRF cookie might have an execution flaw such as: user logs in to site, a CSRF cookie is set; user checks email, clicks on malicious link; link opens in new tab, hijacks CSRF cookie and token; malicious action is executed by the server. Alternatively, a user might simply open two tabs, and try to perform two different actions in each tab, but at least one of those actions will likely be blocked by the CSRF cookie, if it were well-designed (single use, locked to a specific action/user, etc).
There are ways to mitigate these problems, such as supporting multiple tokens in the cookie at once, including a time stamp, action path, user name, a secret value only the server knows, then encrypt everything into the CSRF token using AES or another secure encryption algorithm. Just be aware that all of this has to be designed perfectly right, or you'll have a gaping wide CSRF problem in your application, and you might not even realize it. A better choice would be to fix whatever problem it is that's preventing you from putting the token in the URL/form data to begin with.