In more detail
SSRF (server-side request forgery) lets an attacker make a server send requests to places it should not. Features that fetch a user-supplied URL, such as link previews, image importers or webhooks, can be aimed at localhost, private network ranges or cloud metadata services that the attacker cannot reach directly. The server sits inside the trusted network, so it can read internal admin pages and credentials that the outside world is blocked from. Defences: resolve the hostname first and refuse private and loopback addresses, allow only needed schemes, and do not follow redirects blindly.
Why it matters
A "harmless" URL fetcher can become a door into the internal network. Cloud virtual machines usually expose temporary credentials at the link-local address 169.254.169.254, and a successful SSRF against it has led to major data breaches. Checking the text of the URL is not enough, because the same address can be written many ways and DNS can point a harmless-looking name at an internal IP.
Example
An attacker submits http://169.254.169.254/latest/meta-data/ as the "image URL". That address is link-local and not public, so it must be refused. The loopback address 127.0.0.1 can also appear as the decimal number 2130706433 (0x7F000001), as 0x7f.1, or as the IPv6-mapped form ::ffff:127.0.0.1; a filter that only matches the string 127.0.0.1 misses all of these. Parsing the address with a proper library after DNS resolution, then rejecting private, loopback and link-local results, catches them. Related: Localhost, Redirect.
Common confusion
SSRF makes the server send the unwanted request. In CSRF the victim's browser sends it, using the victim's logged-in session.