You need memory. If the server does not remember who clients are and when they were last authenticated, and instead trusts the clients for keeping track of themselves, then the clients are in position to fool the server. What you describe (saving and then resetting the cookie) is called, in all generality, a replay attack. To see things conceptually, with cookie expiration, you are expecting the potential attacker to be graceful enough to forget some sensitive data, where not forgetting it would imply some gain for the attacker.
This leads to two main ways to avoid the issue:
Have the server remember the time of last authentication for each user, and enforce expiration, regardless of whether the client browser did expire the cookie, or not.
Encode in the cookie the expiration date, so that the server can check it. This is offloading the server memory onto the clients; to make it safe (because the client could alter his cookies in order to extend his session lifetime), you then need some cryptography, namely add a MAC computed with a secret key that the server knows but tells nobody (in particular, clients don't know it).
Since cryptography is full of lethal traps, you are encouraged to apply the first kind of solution. This is mostly a matter of adding a column in your table of users, in your database (I assume that you have a database on the server); this will be cheap.
Cookie expiration is not reliable anyway, even in non-hostile contexts, because some users don't set their computer clock correctly. Some are off by several hours (e.g. they are in the wrong time zone), and some are off by several years (they just don't care).