A registration webpage impressed me by knowing all my name, address, email, telephone number.
This is the first time i visit this website.
I guess that it might remember from other website with same id or name such as id="firstname"
id ="telephone" but i don't know exactly what is going on. How to implement this ?
Edit - Add more information.
I have done nothing, value is just appeared as page load.
This is what i got from view source.
<div class="ui-form-field" id="ohfirstNameField">
<input class="ui-form-field-text ui-corner-all" name="ohfirstName" maxlength="4000" type="text" id="ohfirstName" required="required" value="Sarawut" />
</div>
I have seen that before as well, and here is my theory. I believe the browser is storing basic information for you. A separate website cannot read any cookies not generated by itself (that would be a huge security issue), so that can't be it.
I think it is just a few fields that the browser stores. How to get at them, I am not sure. Is this Google Chrome you're talking about?
You could use OpenId to get a similar effect. The user will be asked, if he allows the authenticating site to his data, but if admits it, you will be able to prefill your form with data from the user.
Related
I am working on a project which involves setting up a bunch of dashboards around the office. The plan is to use Screenly on Raspberry Pi 3s, as it seems to fit our needs for the most part at a very low cost. The problem is, some of the webpages that need to be displayed are locked behind a login. Screenly doesn't have a way to get past this, other than passing the login information and the page redirect through the URL itself. I am aware of the potential security issues this could bring, which is why the account we crated for this use can only view (and not edit) very specific pages.
I want to pass login information through a URL in order to login to a website and directly access a specific page on that website. I have had success passing login information in the form of:
https://website.com/dologin.action?username=CapnCrunch&password=Fr00tl00ps&login=Log+in&os_destination=%2Fpages%2Fviewpage.action%3FpageId%58008
This works nicely when the username and password attribute names are always the same, but not when they change on every refresh. Instead of the HTML attributes for the username box remaining the same every time the login page is accessed, they change slightly every time.
For example, these are the HTML attributes for the username upon loading the page for the first time:
<input name="ct100$phUser$txtUser8193" type"text" id="txtUser8193"
class="login_user border-box" placeholder="My Username">
But when I refresh the page, this same bit of HTML code changes to:
<input name="ct100$phUser$txtUser5516" type"text" id="txtUser5516"
class="login_user border-box" placeholder="My Username">
I would love to pass the URL arguments in the form of:
dologin.action?ct100$phUser$txtUserXxXx=CapnCrunch
Where XxXx is just whatever number the page decided to use at that time.
All the solutions I have found online include using external scripts of some kind. The problem is, Screenly only accepts URLs. Using a script would involve either editing Screenly's source code, or using a proxy webpage.
Is there any way to get around the changing attribute name without using external scripts?
Thanks in advance
I have many websites like Facebook where we write a email address and we just click a button, from this a list of email address's rolls down.
Can anyone tell me how this is achieved? Can it be done with just HTML or do i need to learn any other language?
This is accomplished using Javascript or AJAX requests to query the databases "live" and the return a data set. If I understand you correctly like on Facebook where you type in a Friends name and it will pull back a full list of names which may be your friends.
Jquery, Ajax, Javascript, PHP and Mysql would be some good researching points.
It would be worth searching for "How to create a PHP Ajax request to auto populate HTML fields"
If you are referring to Auto Complete within a browser this is a local setting which is controlled by the end user or their administrator and from what I am aware from HTML alone you can not manipulate this.
I fully agree with Steve's answer. In addition you might want to check out the following:
http://ajaxdump.com/2010/08/11/10-cool-auto-complete-scripts-using-ajaxjquerymootoolsprototype/
http://www.freshdesignweb.com/jquery-ajax-autocomplete-plugins.html
Hope it will help you
Well i go on and search a lot and then i found this is very simple!!
you just need is to type autocomplete = "on" and give it a name and then make a submit button
the code goes here:
<input type="text" name="Name" autocomplete="on" />
<input type="submit" />
I've researched it and cannot find a standard, dependable way to make a browser prevent autofill and not remember the password in a standard login form.
This is important to me as I'm working on a mobile web app, so if the user clicks logout and someone else gets hold of their phone, the browser shouldn't help them out by just handing them the password!
The only solution I can come up with is to make the password field type="text".
Sure, this would mean people can 'shoulder surf' and see what the user is typing in, but that same person could almost as easily just watch the user's fingers to see what password they're typing in...
I don't think spyware is a real issue here either, as I don't think a type="password" character mask is going to stop a malicious keylogger, etc. from doing its stuff.
So, I'm wondering if there are any other security concerns that I may have missed for using type="text" for a password field?
Maybe if I combined this idea with a dynamic/random 'name' attribute for the input, could I be onto a winner?
NB - The solution needs to be compliant with XHTML Mobile Profile.
Also, please refrain from advising me on what is semantically correct here. My priority is security, not semantics. :)
Bad idea - The browser will remember text fields, it just wont enter them automatically as it does with passwords. Instead it will suggest the password as an autocomplete for all to see. I also think reading a password over someones shoulder is much easier than reading their keystrokes.
The reason some browsers dont respect the autocomplete option for passwords is probably because passwords are handled by a separate (in theory more secure) method for handling/storing password data - obviously by using a text field you are bypassing this system with whatever risks that entails.
I dont think there is a definitive solution that doesnt involve js, since at the end of the day you have no real control over what their browser remembers. You can only provide hints and suggestions. Which will be handled in different ways by different browsers. Your best bet is to start by adding :
autocomplete="off"
to your form and input. Works in most browsers - but not all.
The above would go in your form tag and your password input tag, something like:
<form id="form1_randomstring" name="form1" method="post" action="process.php" autocomplete="off">
<input name="password_randomstring" type="password" value="">
As you said in your question, randomizing the form and input names will also trick some browsers into thinking it is dealing with a different form
Also, browser will be extra conservative about what they remember if you use ssl. So this may help.
Finally, as another layer of protection you could have a little onload jquery to clear the form field manually on docready:
$("input[type='password']").val('');
Obviously no help if not running js.
The Definitive solution (maybe?)
You could go a step further and inject the form field using an ajax call (plus generating the random form names + autocomplete and serving the page through ssl). Meaning js would be a requirement for logon but you could then make sure the field was clear and generate the form after page load. I would challenge any browser to complete it then.
If you went for that option both the outer page and the ajax loaded page would have to run through ssl - If you didnt want this an alternative might be to load the ssl form through an iframe (again trade-offs -user base would need to be considered.)
Depending on your requirements and userbase, this could present the most guaranteed option.
NOTE
Autocomplete="off" may not pass strict XHTML validation. An option then may be to add the autocomplete attribute after page load with jquery (again, obviously this wont work without js enabled):
$('#form1').attr('autocomplete', 'off');
As an added point, The simplest way to prevent a key logger would be to provide a select option drop down box and ask them to enter a letter/number from their password. Practically speaking you would have to limit passwords to alphanumeric and ask the user to enter at least three letters/numbers from their password in a series of drop downs.
Summary
No perfect solution but lots of options, you'll have to consider what is right for you. I would maybe go for the ajax call as the main method. You could initially load a link to the form and dynamically replace it with the ajax content so that there is still an option for non js users (less users compromised by autocomplete)
I am having trouble trying to find a solution for this, without resorting to a php statement, or javascript. This is as the idea seems so simple, that i am pretty sure there must be a way to do this without the use of the two.
I have a registration form, and certain fields on this form are required. But i have come to kind of a quandry, because i require the user to enter atleast one phone number, so that they may be contacted incase there is a problem with their order.
So i have 3 fields, "Phone" "Mobile" "Fax"
What i want to do, is make it so the user must enter either a phone, or mobile number in order to complete the form.
But, i guess my question is this... Is it possible to use the required attribute in some way, in order to achieve this effect?
Here is the html for these fields:
<li>
<label for="phone">Phone:</label>
<input type="tel" name="phone" id="phone" value="'.htmlout($phone).'" required aria-required="true" placeholder="0317021101"title="Please enter your home or work number here. You must enter either a phone, or mobile number." maxlength="20"/>
</li>
<li>
<label for="mobile">Mobile:</label>
<input type="tel" name="mobile" id="mobile" value="'.htmlout($mobile).'" placeholder="0827564829" title="Please enter your mobile number here. You must enter either a mobile, or phone number." maxlength="20"/>
</li>
In assistance, input or advice regarding this would be greatly appreciated, thank you!
Wouldn’t it be simpler to have two phone number fields, the first of them required? The explanations seem to say that either of the numbers can be a mobile number or something else, so why not make them symmetric in structure?
The first could be labeled “Primary phone (required)” and the other “Secondary phone (optional)”. These are rather long for labels, but in my experience, too short labels (like “Phone” and “Alternate phone”) tend to make some users re-type the first number...
Unfortunately, required only works on individual fields and not groups of fields (even if they have the same name), so there is no way to do this with HTML5 validation alone.
Demo: http://jsfiddle.net/ka7kC/
You shouldn't rely on client-side validation anyways, you have to validate on the server side as well. Besides, not all browsers even support HTML5 validation.
If you're using jQuery, I suggest the tried-and-true validation plugin for the client side:
http://bassistance.de/jquery-plugins/jquery-plugin-validation/
If it's actually required, only a server-side validation script can actually enforce it.
Javascript is really the only other option to do complex (ie. anything more than pattern matching) validation client-side.
The "required" attribute doesn't work in most versions of IE and some versions of Safari so you'd want to validate your input another way.
This is kind of crazy.
Here's a form on our OpenID provider:
<form method="post" action="/affiliate/form/login/submit?affId=7" autocomplete="off">
<table class="position-table">
<tr>
<td class="input-td">
<input class="framed-text-field" type="text" name="email" id="email" value="" maxlength="100" />
<span class="form-help">name#example.com</span>
</td>
<td class="input-td">
<input class="framed-text-field" type="password" name="password" id="password" />
<span class="form-help">Password</span>
</td>
<td></td>
<td class="input-td">
<input type="submit" class="affiliate-button" value="Sign In" />
</td>
</tr>
</table>
<input type="hidden" id="fkey" name="fkey" value="REDACTED" />
</form>
This form is part of a page (at /affiliate/form/login) hosted in an iframe. The iframe is served over HTTPS, the host page over HTTP. You can see this in action at /users/login using an incognito/private-browsing/porn-mode browser window.
So here's the problem, periodically (but not consistently) a user will GET instead of POST to this url. This is an absurdly low occurrence, affecting less than 50 total users to date.
I'm tempted to just dev/null these errors (no action method etc. etc.), but...
These look like real users: wide spread of IPs, varied and valid user agents, and believable timings. Frustratingly, the same users sometimes successfully POST the same form just a bit later.
Any ideas what might be causing this?
Ideas I've had and discarded:
HTTPS accelerator or load balancer munging requests
checked incoming logs, they match what's getting to the app
ASP/.NET request parsing error
Compared incoming to logged Request values, they match
Buggy browser
Logged occurrences in multiple Chrome versions, FireFox 4, Safari, and Mobile Safari
Bots, or crummy browser extensions
Wide browser, IP, and OS spread.
My current best guess is that the ?affId=# in the action is tripping something (though not consistently, again). This is basically voodoo debugging, so I'd love a more authoritative explanation.
Update: Tried my voodoo fix (<input type="hidden" name="affId" value="#" /> and so on), and deployed. Haven't got a repro, so I'm just letting it bake.
We see a couple a day on average, so if this bakes for 2+ without issue I'll post it as the answer.
Second Update: Nope, still occurring. Much less frequently however. I'm gathering more data to see if there is any commonality in terms of browsers or operating systems.
Operating theory as to why removing ?affId=# from the action has reduced occurrence is buggy proxies in front of clients optimistically fetching "things that look safe to GET". This is a wild guess, so treat it with a grain of salt.
Third Update: More evidence for bogus proxies. Querying logs for affected IPs (over a much longer period of time), and many of them have much higher request rates than most unaffected ones. Its not 100% cut and dry, and I'm sure some frustrated refreshing is increasing the counts a tad but... its still a reasonable indicator (the difference is 5x or so the # of requests in the same period for the affected IPs).
At this point, I'm moving onto detecting the error has occurred and providing better error messages and guidance. Rather unenthusiastic about actually getting an authoritative answer, especially as that answer seems likely to lie in the realm of "code I don't control".
Some ad-blocking browser extensions like AdBlock Plus Popup addon 'probe' companion pages to determine their real URL before deciding whether to block them. Specifically, the aforementioned Popup addon does this with HEAD queries by default but can be set up to do GET queries.
Had a similar problem with Chrome users and the cause was if someone submits a form using shift+enter in google Chrome, browser will open new tab and make GET request with no parameters. Since people often have uppercase / special character as last character of a password, they press enter before releasing the shift and then GET request is issued.
I see that you mentioned Chrome first when enumerating browsers so if issue happens in Chrome more often, it's probably because of this reason.
While this is probably not the only issue you have, it probably contributes.
Make sure the source HTML is well formatted by running it through a validator.