-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Jun 09, 2016 at 07:49:28AM +0000, Bob wrote:
On Thursday 09 June 2016 07:13 AM, tomas@tuxteam.de wrote:
[...]
Thanks for your explanation. I did "curl -c" but no luck as it
doesn't have any cookie.
curl -c mycookie " http://<link>/login1.html?a=%3F<username>%2B%2F%40&b=%3F<password>%2B%2F%40
"
# ls mycookie
ls: cannot access 'mycookie': No such file or directory
whereas I can see during curl operation
[....]
<body onload="load();">
<form name="myform" method="post" action="http://<link>/login">
<input type="hidden" name="username" />
<input type="hidden" name="password"/>
</form>
</body>
[/...]
The form leads explicitly to a POST request. This is one where
the data is sent in the HTTP body (and not as query parameters
in the URL, as your curl command above is trying).
Some web frameworks accept (equivalently) both variants, some
not.
Try sending as a POST request:
curl -X POST -c mycookie \
-d username=<user> -d password=<pass> \
http://<link>/login
(replacing, of course <user>, <pass>, <link> by more interesting
values. I've broken up the long line with backslashes, don't type
in those).
For more on the -d option and its cousins, look them up in the
curl man page under --data, --data-ascii, --data-binary and
friends.
Is anything in the cookiejar yet?
Issue is, this direct link (which is a redirect link from actual
form page) doesn't create any cookie jar
curl -c mycookie " http://<link>/login1.html?a=%3F<username>%2B%2F%40&b=%3F<password>%2B%2F%40
"
though same is running well on browser and logging in immediately.
--trace-ascii investigation shows as below
~~~~
0000: GET /login1.html?a=%3F<username>%2B%2F%40&b=%3F<password>%2B%2F%4
0040: 0 HTTP/1.1
004c: Host: <link IP>
005b: User-Agent: curl/7.47.0
0074: Accept: */*
...
..
0300: /head>.<body onload="load();">.<form name="myform" method="post"
0340: action="http://1.1.1.1/login";>.<input type="hidden" name="usern
0380: ame" />.<input type="hidden" name="password"/>.</form>.</body>.<
Ouch.
This is, as far as I can see, a "javascript redirect". It reflects on
the sad state of our so-called "industry".
As far as I can see, the browser "bounces" the request to
http://1.1.1.1/login with the same fields. So try to direct your
curl request at this (new?) URI. You don't see the browser doing
that (so it seems there's one more back-and-forth)
Of course, the browser is sending more/different stuff in the header,
like the referer, some string for the user agent, etc. The server
might be acting on some of that information.
That's why I suggested spying on what the browser does and trying
to work from there. It's easier to cut off superfluous stuff from
a "known good" case than to try adding stuff blindly.
Get acquainted either with Wireshark (only if your connection isn't
HTTPS! [1]) or with Firebug. It's both free software.
[1] It's possible to spy on an HTTPS connection with Wireshark. But
for that, you'd have to learn how to get your browser to cough
up the session key and to insert that in Wireshark. That raises
the (already pretty high) bar quite a bit.