How secure is a HTTP GET when the data is URL Encoded?

问题

If the data is Url Encoded, is it secure enough to send login credentials over HTTP GET?

回答1:

Not at all. URL encoded is easily reversible. You should encrypt the transport layer (i.e. use HTTPS)

回答2:

No - URL encoding is meant to make sure all the characters you try to send with a GET request can actually arrive at the other end.

It is actually designed to be easily encoded and decoded to prepare data for transport, not for security.

回答3:

URL encoding is not any kind of encryption, it just prepares the string to be sent through the network.

If your data is sensitive, GET should be completely out of question. Reasons for this?

The obvious one, everyone who takes a peek at the URL bar, will see the data
The data will be left in every proxy log that it passes trough
If the user leaves the site, the next site will have the URL recorded in it's logs/web statistics (REFERER).

回答4:

Please read the purpose of URL encoding

The specification for URLs (RFC 1738, Dec. '94) poses a problem, in that it limits the use of allowed characters in URLs to only a limited subset of the US-ASCII character set.

HTML, on the other hand, allows the entire range of the ISO-8859-1 (ISO-Latin) character set to be used in documents - and HTML4 expands the allowable range to include all of the Unicode character set as well. In the case of non-ISO-8859-1 characters (characters above FF hex/255 decimal in the Unicode set), they just can not be used in URLs, because there is no safe way to specify character set information in the URL content yet [RFC2396.]

URLs should be encoded everywhere in an HTML document that a URL is referenced to import an object (A, APPLET, AREA, BASE, BGSOUND, BODY, EMBED, FORM, FRAME, IFRAME, ILAYER, IMG, ISINDEX, INPUT, LAYER, LINK, OBJECT, SCRIPT, SOUND, TABLE, TD, TH, and TR elements.)

Security is not the point here. Like already noted, HTTPS should be used when that is required.