Cookies which are sent by the client to your server are just parts of the requests sent by the client to your server, and, as such, should be considered as "potentially hostile" by default. If the client may be an attacker (and it would be quite naive to dismiss this possibility), then anything which the client sends is suspect and could be crafted in order to maximize disruption or do even more evil things. SQL injection attacks, for instance, are a common example of attacks in which the client sends such "bad" requests. Cookies, in that respect, are no different. A cookie is stored on the client side, and the client can alter his cookies as he sees fit.
Since a cookie is meant to be stored "as is" and sent back unaltered (that is, that's what honest clients do), you can include in your cookies a message authentication code: that's a kind of checksum which uses a secret key. This way, your server could verify (by recomputing the checksum on an incoming cookie value) whether the cookie is "genuine", i.e. is a cookie value which was, at some point in time, sent by the server to a client (not necessarily the same client ! If one client can be hostile, two can be hostile as well, and collude). Such a distinction between genuine and crafted cookies can help in protecting your server against hostile cookies; but it won't totally replace care, and, of course, a request contains other elements besides cookies.
Cookies (sent over HTTPS) have security value in another attack scenario: if the client is honest and manages its security properly, then the cookies your server sends to the client will be unaltered during their transit, and will come back untouched, and, moreover, the cookie contents will remain unknown to outsiders (HTTPS relies on SSL/TLS which provides confidentiality and integrity for data in transit). HTTPS protects your server and the client against third parties; it does not protect your server against the client itself.