I have working the auto population of this form: http://getpocket.com/save
I'm using it rather than the API so that it works when users are logged into Pocket on the same browser as my website.
However, it's not a good user experience to then have to click 'save', so how can I "automate" that?
I won't show my code, because it essentially is just to generate a link of the form:
http://getpocket.com/save/?title=thetitle&url=encodedurl
It populates the form fine, but how can I submit? I tried apending &save and &submitand then each of those =True, in vain. Is the issue that the save button doesn't have a name= field, which is what's used to hook into the title and URL fields?
EDIT: Just to be clear, I didn't have any malicious intentions, only to save articles to read later on click of a button.
If I find the time I'll have a look at the API.
Luckily this is impossible (on Pocket and most sites) due to cross site forgery request protection to prevent exactly what you are trying to do.
A token is set in the form and together with session information for the user on pocket (or any other site that uses csfr token protection) it will need to form some sort of secret hash. When the 'save' form is submitted the combination of these strings will be checked and normally new strings will be set. Because there is (practically) no chance that you will be able to predict the token form the form itself and have no real way of manipulating the session hash, you are out of luck. And we are all very happy for that :).
Otherwise you could make links on other sites that would delete your whole database when you happen to click on them, etc.
In short: You can't.
On any form without csrf protection you'd have to target not the url of the page with the form, but the 'action' of the form. You can see this action by inspecting the form with your browser's DOM inspector. But, as I said, csrf protection will prevent this from working most of the time.
http://en.wikipedia.org/wiki/Cross-site_request_forgery
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
Related
I've seen questions around both submitting to self (same url) and submitting to different url. Which one is the right way to go?
Neither is "right". Both are fine. Use whichever one suits your needs.
Submitting to a different URL can simplify keeping your "show form" and "process submission" logic separate (and thus easier to maintain).
Submitting to the same URL simplifies redisplaying the form with error messages if the user makes an error in their input.
I tried to look through SO for similar question but I couldn't find one, also searched through the web with my best effort, sorry if it's a silly/duplicate question
The focus of my question is :
If I have a form with a unencoded password in it, is it "safe" to pass the form back to [self] i.e. <form action="">
EDIT: I would like to focus on security regarding third parties, assuming the user himself is NOT the hacker.
I this is a broad question, so I would like to narrow it down to:
does server handle submit form to self as a internal-forward thing or do it actually treat is as a normal server-to-server http call?
Is it possible to somehow intercept the form submit and extract the password from this action? (including things like tapping the connect between server and client??)
If anyone knows any potential security problem in general for [submit to self], feel free to leave it as answer so that future SO user might benefit from it, thanks.
The only thing safe regarding submitting data to a webpage is to never trust the users input.
Now regarding your 2 questions:
submitting the form will be handled as a regular request, albeit a POST request probably.
internet traffic can be captured, so if you're sending password data over the internet you'd better make sure it's over HTTPS.
Using a developer tool like Mozilla's FireBug it's pretty easy to change all the data that is submitted through the form. You don't even have to use your webpage, one can easily spoof a POST request to your page by using a tool like Telnet.
So I'd say it doesn't really matter what the action of the form is; use HTTPS if possible and always validate the input...
Whether you submit your form to the same page or not has no security implications. There are many other things you can/should do to secure your forms. Submitting-to-self is irrelevant. It could however pose a UX annoyance. Have you ever tried refreshing a page only to have the browser try to resubmit the form.
Not a redirect. Normal post. However to mitigate this UX annoyance I
mentioned, you would redirect to the same page after doing whatever
you need to to with the data.
It depends on many other things other than whether the form submits to itself or not. Starting with is your form on a secure (https) server.
I was just searching for this types of posts.
Yeah..
As far as i know, this is not a valid approach,
attacker can change the methods to download the content like he can use the parameters from POST to GET.
We actually have tools like tamper data which is an addon to the firefox browser. We can post the data or tamper the data which is in form submit. You can add this addon to your browser and you can check out that the data can be modified by clicking tamper before submitting the form. You can also check out the online http tampers, tamper data, modifying live headers to change your data. This may also result in sql injection.
Correct me if im wrong. :)
Cheers.
After many updates:
The action="" is the same as action="somefile" in sense of security. So there is nothing wrong with action="", and as far I know most websites treats forms like that. The most popular solution is to:
At first check with PHP if there is any post data
Check if this data is OK (safety, server side verification)
Make something with data (save to database, mail to someone)
Render the form with action="".
A quick example:
<?php
$name = '';
if (isset $_POST['name']) {
$name = $_POST['name'];
if (ctype_alpha(str_replace(' ', '', $name)) !== false) { // verify data
// in that case name consist only letters and spaces, it is ok.
// do something with data here, for example save to database
header('Location: successfile'); // Remove post data after all
}
}
// render form
$name = htmlspecialchars($name); // if name was in POST, here it is!
echo '<form action="" method="post" />'
echo '<label id="name" name="name" value="'.$name.'" />';
echo '</form>';
?>
In that case one file is doing two jobs. It checks for data and do something with it, and render form.
Please, remember that the form can be rendered using the "partly" data from submit (POST). So for example if someone enter his name with special characters, while you need name only with letters and spaces, the data is not missed. You can render form, and in input name value, you can enter the wrong posted data.
So the form "remember" what was filled, and what was not filled.
Hope it helps
When I submit a form with a password field in, for example, Firefox, the browser asks me if I'd like it to remember the username and password for me. For example, logging into gmail in Firefox, I get this message in a popup:
Would you like to remember the password for "markamery#gmail.com" on google.com?
with 'Remember password', 'Not now' and 'Never for this site' options.
I'm developing a plugin that will be used to provide a service on multiple websites. Users will have an account on our mysite.com, and our clients, like someclient.com, include a Javascript script from mysite.com on their webpages which adds our content and functionality to their page, including a login form that users can use to sign in to our site. (The actual mechanics of the login process are all handled with iframes, AJAX and HTML5 postMessages, not that it matters).
When users log into our plugin on someclient.com, I want their browser to prompt them to remember the password on mysite.com, and when they see our login form on someotherclient.com, I want it to be autocompleted with the same username and password that they entered into it on someclient.com. However, currently, they get a prompt asking
Would you like to remember the password for "yourname" on someclient.com?
instead, which isn't what I want.
Is what I want possible, and if so, how?
Putting the form inside an iframe will cause Firefox at least to associate any stored passwords with the domain of the iframe instead of that of the main page. You can communicate with the iframe using postMessages.
Just have the iframe catch the form submit event, serialise the content of the form, and send it to the main window via postMessage; then the main window can grab the content of the form from the message and handle it using Javascript.
Of course, even in simple cases this is a fairly ugly hack, and if there are complicated interactions between content in the iframe and content or code in the main page, then trying to handle them all properly via postMessage may result in a quick descent into pain and spaghetti. If the value of having cross-domain password autocompletion is low and the main issue is that having a remember password message featuring the wrong domain name is bad, then consider simply disabling the feature altogether instead of mutilating your codebase with hacks to fix it. You can disable it by setting the 'autocomplete' attribute of the form to 'off', as described here: Disable browser 'Save Password' functionality
I need to know how to fill an web form using Delphi XE3? I have a web form with user name and password, so how to fill it programmatically?
The page is http://batelco.com/portal see only two inputs user name and pass so how to fill and pass them ?
Using Internet Direct (Indy) HTTP client class, you can submit form values to the server using HTTP POST.
The Indy HTTP client will also receive and store cookies which the server sends with its response, if an instance of the TIdCookieManager class has been assigned to the IdHTTP client component.
HTTP cookies are required by many secure web applications when the client makes further HTTP requests to other secured URL on the server. The Indy HTTP client then will send the cookies with the request (if a TIdCookieManager has been assigned to the IdHTTP client component).
So you could send a login POST request on the login URL, providing needed authentication information, and then send a GET request to the download statistics URL to retrieve its HTML.
Regarding your specific login form, which uses ASP, here is a question about programmatically sending POST requests: HowTo deal with cryptic hidden values for ASP Net (__VIEWSTATE)
This article shows how to get and set properties of named elements.
You should get and set value properties. What ID's would form elements have depends upon your page.
Check if Element with ID has a value
This article while asked "how to read" also describes both how to get values and how to set them. Afterall if you can do A := B (read value), then you probably can also do B := A (set value).
read content in webbrowser input field
Now, that the page URL is given in the question we can click on the right top corner login-form elements in WWW browser with right button, and choose "Inspect element" to see its sources. Or, if browser is not modern and does not have Inspect command on menu, we can use another commend, like View page source and find form in the sources of the whole page. For example one of those elements is
<input name="txtUsername" type="text" maxlength="15"
id="txtUsername" tabindex="1" class="inpu-field" onfocus="txtfocus();"
onblur="txtblur();" style="color: gray; background-image: none;">
Thus we know know the ID of 1st element of form, whose "value" attribute we need to get(read) or set(write).
Links above show how to do it, given the known ID.
BTW, you given your page wrong, the real page is https://www.e-services.com.bh/Eservices/login_batelco.aspx
What about your original page, it just does not work with MSIE6 that is TWebBrowser in default mode - for compatibility with all the written applications using Microsoft ActiveX component. See http://imgur.com/ad4wbOI
If can use Google Chrome instead of TWebBrowser.
Or you can reach the ActiveX interface as one of TWebBrowser properties, and acquire new interface and turn off MSIE6-compatibility http://msdn.microsoft.com/en-us/library/aa752510.aspx
However, "how to make this page render in twebbrowser" is another, new question, not the question you asked here.
Actually, the only reason why i do not vote for closing this question as duplicate, is because none of articles above have "set" or "write" or "fill" in their title, so finding them was a bit harder than trivial.
But if the page is not mutating on load and does not have some one-time protection like CAPTCHA or unique form hash-codes, then you can post all the values with single HTTP request without even loading the form.
I have a profile edit page on my website with preset age and country lists so people can choose their age and country.
My problem is a guy made an HTML form that can submit a custom age and country. Does somebody know how to block form submitting from websites that are not on my domain?
I changed my form a few times, but he can find the input names just as simply as I changed them.
The only fail-safe way to prevent a submission of a form with undesirable values is to perform validation on server side.
I think the referrer (Request.ServerVariables("http_referrer")) should tell you the page the request came from. As Oleg said you should additionally validate the returned form data in any case.