GET, POST, CGI submitting questions ??

I'm sure all of you have seen something like this:

"POST /root/level1/blabla.php?login=admin&password=password HTTP/1.0"

My questions...

Where is it specified that we have to use '?' and '&' in this way. Is it a specification of CGI of HTML or what?
Why can't we use spaces and have to use these characters? There is space before HTTP/1.0, is it not?
Are these the same characters that you'd use in telnet to retrieve the pages or do they (telnet) conform to a different set of rules?
Are there more characters to use in CGI like this?

Pls post any good links. I read the http://www.ietf.org/rfc/rfc2616.txt but i feel that it doesn't explain things in a manner I'd understand from my background (LAN, Java). I'd really like to learn about how is the CGI build and what are other ways to enable user/website communication.

the ? in php tells php you are about to assign a value to a variable, the & is used to string together multiple variables. To my knowledge, that space would bust the form submittion. But my PHP knowledge is limited.

here is a good URL http://www.php.net/manual/en/ini.core.php

My php knowledge is also limited, but from what I understand, the ? indicates that arguments follow and the & is the argument seperators. as for the space, it is not there to help in the php string.

As seen on the above URL:
arg_separator.output "&"
arg_separator.input "&"

The "HTTP/1.0 \n\n" has to be part of all HTTP request to define which protocol is being used. When using a browser, the browser takes care of inputting it, but if you use telnet, you must supply it to complete the POST.

Another good place to find out what certain variables are and what they are set to would be the php.ini as indicated by the URL posted above.

Am I 100 percent correct? probably not, I relied on google and the limited programming background I have.

If memory serves, you shouldn't ever see a POST and arguements separated by a &...

For starters, look at the <form> element definitions...
http://www.w3schools.com/tags/tag_form.asp

Specifically:

Quote:

---

method get
post The HTTP method for sending data to the action URL. Default is get.

method="get": This method sends the form contents in the URL: URL?name=value&name=value. Note: If the form values contains non-ASCII characters or exceeds 100 characters you MUST use method="post".

method="post": This method sends the form contents in the body of the request. Note: Most browsers are unable to bookmark post requests.

---

So from here, you can see that you dictate how the browser responds with the method of the form. GET is by far the simplest and when the cgi is called (as defined by action), the arguments will be supplied as a '&' separated list. The difference with POST is that the arguments are still separated with '&'; however, they are passed after the request and require that the content-length be sent (and be correct) of the arguments. This difference is reflected on the address line of your browser, a form using GET will have all the arguments (like you listed), whereas a POST will just have the form URL (and the arguments are in the body). When you receive the arguments, the will be further separated into a token=value list, where the token is defined as the name of the element that took the value. For example, if you had <input type=text name=foo> and the value was bar, then the token passed would be foo=bar.

So lets say you have two elements named foo and foo2 and their values are bar and bar2 respectively...and the form dicates the action is handled by mycgi.cgi @ someserver.com...

For a GET, the transaction/request, when connected at the socket level will look like: (using telnet you can type this on the server once connected on port 80, or whichever port, caps are important)

GET mycgi.cgi?foo=bar&foo2=bar2 HTTP/1.0 \n\n
-- or --
GET mycgi.cgi?foo=bar&foo2=bar2 HTTP/1.1 \n
Host: someserver.com\n\n

For a POST its a little trickier (and I usually use something like achilles or curl to do it for me rather than hand cranking):

POST mycgi.cgi HTTP/1.1\n
Host: someserver.com\n
Content-Length: 17\n
\n
foo=bar&foo2=bar2\n\n

\n == new line, also note that 17 was a simple character/byte count.

IF the GET method was used, the environmental variable QUERY_STRING will be set (and can be queried by your cgi language of choice) and if POST was used, you'll have to read the input from STDIN using teh environment variable CONTENT_LENGTH to know how much to read into the buffer. In either case, you'll still have at some point a string equal to "foo=bar&foo2=bar2" and you can use your language of choices string functions to split out the arguments and do whatever it is that you wished to do, with a special caution to make sure you check your input for invalid/malicous characters...

I think I am starting to digress...did explaining the interaction of the HTML form and the CGI and how the browser passes the arguments on answer your question ?

Quote:

---

... To my knowledge, that space would bust the form submittion ...

---

use "%20" instead of space and as usually without quotes.




- :S:

a example for negotiation:

Quote:

---

started....
WWWConnect::Connect("www.antionline.com","80")\n
IP = "63.146.109.212:80"\n
source port: 1380\r\n
ISC_REQ_MUTUAL_AUTH | ISC_REQ_DELEGATE set\n
SEC_I_CONTINUE_NEEDED\n
REQUEST: **************\n
POST / HTTP/1.1\r\n
Host: www.antionline.com\r\n
Accept: */*\r\n
Connection: Keep-Alive\r\n
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4AAAAAAAAAAAAAAAAAAAAAA=\r\n
\r\n
RESPONSE: **************\n
HTTP/1.1 200 OK\r\n
Date: Wed, 05 Oct 2005 00:23:24 GMT\r\n
Server: Apache\r\n
Set-Cookie: ; path=/; domain=.antionline.com\r\n
Set-Cookie: bblastvisit=1128471805; expires=Thu, 05-Oct-06 00:23:25 GMT; path=/; domain=.antionline.com\r\n
Content-Length: 71866\r\n
Connection: close\r\n
Content-Type: text/html\r\n
\r\n
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">\r\n
<HTML>\r\n
<HEAD>\r\n
<META NAME="keywords" CONTENT="ip locator, lsass.exe, exploits, hacking, antionline, computer security, hackers, aim, phreaking, virus, patches, highja
WWWConnect::Close("www.antionline.com","80")\n
closed source port: 1380\r\n
finished.

---

this is the communication method for www browsers


saludos

can i do the EXACT same thing w/ telnet or no???

Quote:

---

Originally posted here by unhappy
can i do the EXACT same thing w/ telnet or no???

---

Yes.. Any character based connection would do.. NetCat i.e.

Keep in mind, that you don't need most of the tokens that are listed in the previous example to get a simple web page, they each have their purpose and meaning, the bare minimum that I provided should work for most any site and can be used by any connection (telnet, netcat, or even something like a perl socket). There are a set of special characters (as dicated by HTTP/HTML) that have to be encoded with Unicode, among them are space (%20), EOL (\n, %0a), NULL (%00), + (%2b), < (%3c), > (%3e), % (%25), ? (%3f), = (%3d), ( (%28), ) (%29), . (%2e), / (%2f) ...

To illustrate the passing of the arguments (and show it in code), I am going to provide two different ways in perl to get a web page. The first one to me is the most interesting, since I am actually more closely controlling what is sent; however, both accomplish the same thing.

A simple HTTP socket program (two ways):

Takes 2 arguments from command line, IP of the server and port of the server and then connects and does a simple get on the root directory of web server. Its a little more complicated than maybe necessary since to speed up the post I copied it from something I had written earlier (that I might share at some point). The point being, that the connection is made to the server and the same strings we have been discussing have been passed...

To show you it works, I will put in the response from Antionline :)

Code:

---

#!/usr/bin/perl

use strict;
use IO::Socket::INET;

our $argc = @ARGV;                                          # number of command line arguments
our %args = {};
our $eol = "\r\n";
our $tokens="User-Agent: User-Agent: Mozilla/2.0 (compatible; MS FrontPage 5.0)\r\nPragma: No-cache\r\nConnection: close\r\n";
# constant user-agent tokens (except for frontpage)
our $hn = "";                                              # hostname (reverse DNS name of target)
our $server = "";                                          # IP of server to attack
our $port = "";                                            # port where web server lives
our $httpm = "HTTP/1.1";                                    # HTTP method

if($argc == 2)
{
        $server = @ARGV[0];
        $port = @ARGV[1];
# note to make this short, no error checking...could be a bad thing
        $_ = $server;
        my @ocs = split(/\./);
        my $addr = pack('C4', (@ocs));
        $hn = "noname";
        my @addrs = ();
        ($hn, @addrs) = gethostbyaddr($addr, AF_INET);
        if($hn eq "noname" || $hn eq "") { $hn = $server; }

} # end of check for arguments
else
{
        exit 1;
}

my $s;                                                  # socket
my $response;                                          # place to hold result
my $request;                                            # string to send
my $mydir = "/";
my $to = 5;

        my $s = IO::Socket::INET->new(Proto => 'tcp', PeerAddr => $server, PeerPort => $port, TimeOut => $to);

        if(! $s)
        {
            die "Error connecting to $server:$port :  $!\n";
        }
        $s->autoflush(1);                                              # flush buffers/no buffers
        $request = "GET " . $mydir . " " . $httpm . $eol;
        $request = $request . "Host: " . $hn . $eol;
        $request = $request . $tokens;
        $request = $request . $eol . $eol;

        print $s "$request";
        my $temp = "";
        while(defined ($temp = <$s>) )
        {
                $response = $response . $temp;
        }
        close($s);
#      print "Request: $request";
        print "Server response:\n$response\n";

---

Quote:

---

./http.pl 63.146.109.212 80
Server response:
HTTP/1.1 200 OK
Date: Wed, 05 Oct 2005 14:17:55 GMT
Server: Apache
Set-Cookie: ; path=/; domain=.antionline.com
Set-Cookie: bblastvisit=1128521875; expires=Thu, 05-Oct-06 14:17:55 GMT; path=/; domain=.antionline.com
Content-Length: 71803
Connection: close
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>

---

In the previous snippet, you were actually handling the connections yourself; however, there is a perl module for doing this kind of thing (I tend to do things the hard way, but anyway, I have written a couple of things that used it). As you can see the code is a little cleaner:

Code:

---

#!/usr/bin/perl

use Net::HTTP;
use strict;

my $argc = @ARGV;
my $server = undef;

if($argc == 1)
{
        $server = @ARGV[0];
# note to make this short, no error checking...could be a bad thing
} # end of check for arguments
else
{
        exit 1;
}

my $httpskt = Net::HTTP->new(Host => "$server", HTTPVersion => "1.0") || die $@;

        $httpskt->write_request(GET => "/", 'User-Agent' => "Mozilla/5.0");
        my($code, $mess, %h) = $httpskt->read_response_headers;

        while (1) {
          my $buf;
          my $n = $httpskt->read_entity_body($buf, 1024);
          die "read failed: $!" unless defined $n;
          last unless $n;
          print $buf;
        }

---

Results: (note headers from server aren't there, you have to specifically ask for them from this module, which I didn't in the code)

Quote:

---

./http2.pl www.antionline.com
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>

---

Anyway, from the first example, you can see that I don't pass that many arguments...

As the websites get more complicated and your needs get more complicated, so will your use/understanding of the different tokens that are passed around (for example, the content-type can be important and allow for transfering of binary files if you program it correctly) and you will also have to take into consideration authorization and a few other things, but for most websites you really only need the basic things that I have mentioned...as you can see it worked even here; however, since I didn't do any authorization, I only had guest privelages when seeing the page, but that is a discussion for later :)

Quote:

---

my $httpskt = Net::HTTP->new(Host => "$server", HTTPVersion => "1.0") || die $@;

---

keep alive? and HTTPVersion '1.0' i try with 1.1 and the results is good



good code and explanation ;)


AzRaEL

Well...the 1.1 is starting to be more prevalent now, the reason I chose 1.0 is because 1.1 will cause an error on older servers, but 1.0 will usually work with both...

Keep-alive that has to do with the connection state...basically what that means is that you don't have to keep reconnecting to the webserver to do another transaction...like for example, say you have a web page with 3 gifs on it...you could have 4 connections:

GET /index.html HTTP/1.0
GET /gif1.gif HTTP/1.0
GET /gfi2.gif HTTP/1.0
GET /gfi3.gif HTTP/1.0

With the keep-alive, what that means is you can, rather than tearing down the connection and opening a new one, you can issue a new request after the server responds for the original one...Its really up to you how you want to handle it, I like for scripting keeping it separate to keep up with it, which is why I have Connection: close on mine instead of COnnection: keep-alive. Also note that how you do the 'print' statements controls what it sends out int he packet...the way I have it now it sends the request all at once...but if you wanted to send GET /in in one packet and dex.html in another packet, you would just issue two print statements...no comments on why you might want to do that :)