SMS Gateway

Hey! It aint that hard!

Postby SOD » 03/06/09, 5:07 pm

This is not about debate...
It is not about transmission. I asked about certs encryption etc in one of my posts.

Without POST sensitive information could be cached on a UA that is not in a trusted environment. Does that sound secure?

So if you use POST at the HTML level instead of GET you have secured the data locally and then it does not matter if the UA is in a trusted environment at least you protect the information from being read from history. It is more secure.

So at the UA <i>layer</i> then you have done all you can do to protect the user from becoming
a victim of data theft.

Gerry sez: POST isn't more secure than GET, POST just makes the location of the data a little less obvious.

Many an identity theft begins by reading the carbon that the charge receipt left behind. 8)

@Gerry about debate:
You attempted to debase the arguments by changing their relative attributes to generic. You did this systematically. I even said that when you consider security for a web app it is all about case management. You will have to do better than that. No waffling the attributes of an argument :P

Developers word of the day: Intrinsic
It is better to be here than there - SOD
SOD
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5284
Joined: 12/06/01, 12:00 am
Location: here and there

Postby Dark Shadow » 03/06/09, 9:27 pm

SOD:

There is a 256bit signed SSL on the site in addition to the fact that if you have machines between your server and ustxt.net that are listening to traffic encrypted or not, you have bigger issues than just GET vs POST.

GET is less obvious to sniffers but more obvious to humans. POST is more obvious to sniffers but less obvious to humans. URIs can be recorded by machines stitting between you and the target but so can POST data and spoofed security certificates, man in the middle attacks, etc...

According to w3.org, GET is just as secure as POST is and is a perfectly acceptable way to transmit sensative information with the exception of placing sensative information into the URI via GET.
http://www.w3.org/2001/tag/doc/whenToUs ... #sensitive

And as far as URI length limit of 100 characters goes, I have a simple print variable page on the ustxt.net site to show that a GET request can be longer than 500 characters (not sure what the exact limit is).
Code: Select all
http://www.ustxt.net/test.php?test=insert500charstringhere


Hopefully this clears up a few things.
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Postby SOD » 03/08/09, 4:15 pm

OK numb nuts since you don't believe me perhaps you would believe the W3C.

The section you are looking for is:
15.1.3 Encoding Sensitive Information in URI's

" Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead"

http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html
It is better to be here than there - SOD
SOD
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5284
Joined: 12/06/01, 12:00 am
Location: here and there

Postby SOD » 03/08/09, 4:49 pm

"And as far as URI length limit of 100 characters goes, I have a simple print variable page on the ustxt.net site to show that a GET request can be longer than 500 characters (not sure what the exact limit is)."

I figured that you would challenge me on the limit the w3Schools set I was hoping that would be enough of a breadcrumb for you to find RFC2616.

According to: MS:
"Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs.

If you are using the GET method, you are limited to a maximum of 2,048 characters, minus the number of characters in the actual path.

However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL.

RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1," does not specify any requirement for URL length.""

http://support.microsoft.com/kb/208427

What is the limit for other browsers?
http://www.boutell.com/newfaq/misc/urllength.html

So that seems vary based on the UA.

For grins here is the RFC:
ftp://ftp.isi.edu/in-notes/rfc2616.txt

The lesson for you and Gerry here is that there is a PROTOCOL layer and a APPLICATION layer. At each layer security must be considered within its CONTEXT.

Hope this helps was really hoping you would have found this on your own.
It is better to be here than there - SOD
SOD
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5284
Joined: 12/06/01, 12:00 am
Location: here and there

Postby Dark Shadow » 03/08/09, 9:17 pm

SOD wrote:" Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead"


I agreed with you SOD when I stated:
"According to w3.org, GET is just as secure as POST is and is a perfectly acceptable way to transmit sensative information with the exception of placing sensative information into the URI via GET."
However, you can pass GET variables to a server without encoding them in the URI.

As for the rest of it, I wasn't challenging you on the hard URI limit of Internet Explorer, or the fact that individual web servers can raise or lower the max size of the URI up to the web browser limit, or the fact that previous, antiquated standards of GET limited it considerably but no one seems to follow those standards anymore. I was simply stating the fact that US Txt.net supports GET variables as long as 500 characters which is far greater in size than is needed for the type of communication it uses. Besides, this is a gateway. Aside from testing, I don't forsee anyone using IE to send data on a consistant basis.
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Postby SOD » 03/09/09, 1:05 pm

WYSIWTF
It is better to be here than there - SOD
SOD
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5284
Joined: 12/06/01, 12:00 am
Location: here and there

Postby Gerry » 03/13/09, 9:23 pm

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

This is a note for clients such as browsers. If they did not include it then it would be an insecure client and one which you should not use.

Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead
It's talking about the most common senario. HTTP is not secure. Servers and proxies can log whatever the hell they like and if somebody is able to browse through your user agent history then your security is already void.
Gerry
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5727
Joined: 12/04/01, 12:00 am
Location: Perth, Western Australia

Previous

Return to Play With Code

Who is online

Users browsing this forum: No registered users and 3 guests

cron