Rob wrote:
> VanguardLH wrote:
>
>> You know what the login.cfm server-side script does? If so, please
>> post a copy of that script here. THAT is what handles the values
>> inputted into the form when the user clicks on the "Login" button.
>> My guess is that it validates the username and password values
>> (i.e., checks syntax)
>
> Probably that is what it does, but this is not relevant for the
> topic. The use of http/https only determines what goes on between the
> browser and the website, not what the website does with the posted
> information. On the server side, the information is decrypted and
> then processed. Any leaks on the server are not affected by the use
> of https.
>
>> and then submits the values to some site.
>
> I see no reason it submits the values to some other site. Why would
> it do that?
>
>> Due to the nature of the web site, I wasn't interested in trying to
>> yank a copy of the server-side login.cfm script to see what it does.
>
> Even if you were interested, you would not be able to get a copy of a
> server-side script.
>
>> Once you get the login.cfm script to know that *it* does with the
>> form values, then you can tell the OP to just WHERE the form data
>> gets sent. I saw no specified destination in the attributes for the
>> <form> tag not in the <input> control with the submit attribute. I
>> saw that it ran a script and that was as far as I was going to take
>> it. I'm not
>
> I have not seen evidence that the server-side script will forward the
> information somewhere else. It probably won't, it will do the
> validation and that's it.
If you look at the HTML code, where in it does it specify to where the
data gets sent? I saw no destination site specified (as in a URL for
the form's data). It has to be in the script.
<form action="login.cfm" method="post">
The destination is specified by the action attribute.
<input type="submit" value=" Login " tabindex="3">
That's the submit button (with "<space>Login<space>" as its label).
From
http://www.w3schools.com/html/html_forms.asp:
"When the user clicks on the "Submit" button, the content of the form is
sent to the server. The form's action attribute defines the name of the
file to send the content to. The file defined in the action attribute
usually does something with the received input."
The action attribute specifies the handler for the paired values from
the form. I'm thinking that you might be right that since the login
page used http: to get retrieved it that the posted data might also sent
via http: because the reference to login.cfm is relative. It is not an
absolute URI. If it had been "action=https
/<somepath>/login.cfm" then
the SSL connection would get made to get to that target so the data
pairs sent there would be secured. I know that with Javascript which is
delivered with the web page (via http) which runs local on your host
using the web browser's interperter that it can send to an https target
to have the data encrypted. I'm not familiar with what are .cfm scripts
(Cold Fusion? And is that a script that's included with the download of
the web page?). With Javascript included in the web page or along with
it, the action attribute would call a function which would run locally
in your web browser. This appears to be a separate script up on the
server so a connection has to be made to it and over which the data gets
sent. So it looks like the login credentials would get sent in the
clear when the OP decided to use http instead of https to access that
web page.
Someone more expert in HTML coding might have to step in. I know that
the form is used to compile a bunch of data pairs used to send them
somewhere. The "where" is specified by the action attribute in the
<form> tag. Here a script is specified but is it a local script
(delivered with the web page) or up on the server? If a server-side
script, its location is relative and that's where my expertise ends
since I don't know if it is possible to deliver a page via http but have
a relative path to a server-side script demand an SSL connection. It
would've been easy to determine if the action's value had been
http
/<somepath>/login.cfm or https
/<somepath>/login.cfm. If the
relative path used to specify the action (destination) for the handler
for the login credentials means they are sent unencrypted, the OP should
contact the web owner to complain that they have a non-secure login
page.
There is a "Login" link on the left (different than the "Login" button)
and it goes to a secure web page:
href="https
/hammertap.auctionstealer.com/secure/login.cfm">Login</a>
If you start at the home page, the "Login" links there also go to the
https target. The "Login" link shown in the left side on any of their
pages goes to an https page. So I don't know why the OP is entering his
own http URL in the address bar of his web browser. The links provided
by the site do go to a secured web page. Whether using http or https,
the URL points to the same page (i.e., the same path). So the *site*
directs you to a secured connection to that page but the OP has chosen
to use his own non-secured connection to that same page. Since the
script doesn't appear to be local to the delivered web page, it would be
a server-side script that would need to get the data pairs from the form
and that would mean the login credentials would get sent in the clear.
The OP should just use the login links provided by the site that use
https instead of using his own fabricated URL that uses http. I suppose
a site could reject an http connect to a web page used for login or
perform a redirect to the same page but using https but that doesn't
happen at this site.
>> I'm interested in helping those that use services or software to snipe eBay
>> auctions in the last 3 seconds and fuck up the real humans trying to
>> submit bids there.
>
> That is a completely different topic unrelated to what is being discussed
> here.
It wasn't to address the issues that were on-topic in this thread. It
mentioned why I chose not to continue assisting the OP. You thought it
would be more appropriate to just say "I won't help you anymore" (which
couldv'e been better addressed by specifying that it was the OP that I
didn't want to help, not discuss further with you).
