How can we submit a form without Javascript and not by pressing any buttons?
I need to transfer a content to another file when a function works under certain conditions. Both the files are written in Perl. The pages are loaded in a webserver(same). I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
But there I didn't find any ways to redirect a URL where the values are transmitted in post method. So I came up with the form submission. But the problem is I need to use javascript or make user to press a button to complete the task.
The problem with Js is there some users who disable JS in their browsers.
So using it is not preferable. With the button,
I can't make the user to do that for me.
Is there any other scripting language, which supports such functionality?
There are some conditions that I can't use session
What I did is encryption for identifying the user from knowing what data is transmitted. The receiving page will decrypt it when it is required. But it's not what I needed.
I need to transfer a value, which the user doesn't want to know what I'm sending. So I came up with the post method is safe.
It isn't. If you pass it through the user's browser, then the user can see it.
Is there any other scripting language, which supports such functionality?
No. There is no programming language as well supported in browsers as JavaScript, and none that are harder to disable then JS.
Store the value on the server (you could use a session) and redirect the user with a normal 302 status and Location header. You can pass a session token via cookies or the query string.
You can't make a user do anything, unless you're writing for a browser the equivalent of a trojan.
But secondly, without something on the client side, you can't ensure that you can get information that you didn't have when you sent the page.
You could place some links, and know which links they clicked on by passing it through a central tracking program, but those links wouldn't have anything in them that didn't originate on the server without client script running.
Still, despite that you can entice a user to click on a link more than a simply functional button, in either case you can't get guaranteed new information from them. They can always close the tab, close the browser, or press the back button. This goes back to point #1: you can't make users do anything.
Related
I am looking for a deeper explanation of the html form action attribute than is usually given. What is really happening when the user hits 'submit' in the browser? I assume that the browser sends some kind of message to the web server software. So the browser is communicating with for instance Nginx.
But the way people talk about the action attribute makes it sound as if the browser is really sending the data to some arbitrary URL. Like to a php script located at that URL, but that doesn't really make sense to me. Is the form data really being sent to the web server and then the web server parses the action attribute and attempts to somehow submit the parameters and values to a script located there? In that case the URL specified by the action attribute would really be more like a suggestion to the web server.
Can someone explain to me what is really going on? I find the idea of the form data being sent to a 'where' or anything other than to the web server quite confusing and I have not been able to find a deeper explanation anywhere. All paths seem to lead to the concept of the form data being sent to some URL as if that actually made sense.
In my site, users can only modify their personal information only once a day. Script-side, I determine if they are allowed to (i.e. check with the database if it's been 24 hours since the last modification) and whether or not to display the form.
My question is, could a malicious user manage to submit information if there's no form? In other words, if there is no FORM element no data should be submitted by the user's browser, right?
What I'm afraid of is that if someone manages to send the data, the script would still process it and change the personal information when it shouldn't.
Of course - this would be a kind of replay attack. So long as your resource endpoint will handle a malicious POST request, regardless of the content of the preceding GET then you're vulnerable.
Remember: never trust the client. Provided that you do authentication and authorization checks before handling a POST request then you'll be fine.
Yes, a malicious user can still send data even without the form, if he knows the url of the page which accepts the data and their corresponding attributes it expects. He can then easily create a form with that info and submit the data.
So you basically need to validate the data at the server-side.
YES
For example someone could use curl.
curl -d profile=value http://www.yoursite.com/profile
You could prevent such attacks with a CSRF token you send along with your form.
See this article for more background http://shiflett.org/articles/cross-site-request-forgeries.
Suppose I am going to create a web page with two box, for entering the user id and user password respectively. And then once i click the submit button, it will check with the database in background whether this user exist. If it matches anyone in the database, the user id and user password will be forwarded to the other page, at the same time it will redirect to that user's main page.
Can I just use servlet to complete this task?
I found there is request.Dispatcher API but is it enough for the task?
String name = "Tom"
request.setAttribute("name",name);
RequestDispatcher dis = request.getRequestDispatcher
("Servlet2");
request.Forward(request,response);
in second servlet file
request.getAttribute("name");
//this line will display "Tom"
One more question to ask, how about clicking a link (INSTEAD OF BUTTON) to pass some data and redirect to other servlet pages? Any idea? Many thanks for your reply.
Yes, you can use a servlet for this. Whether the dispatcher is enough or not depends on the concrete functional requirements which are not fully clear from your question. The canonical approach, however, is to store the logged-in user in the session scope instead of in the request scope. Otherwise the user has to login everytime the user want to visit a restricted page.
Also, you normally would like to send a redirect after the login succeeds. This way the new URL get reflected in browser's address bar. Also this way pressing F5 afterwards won't cause any possible surprises. Forwarding from one to another servlet is at its own also somewhat a design smell. Including would have been reasonable, but forwarding not. As said, send a redirect instead.
As to using a link to submit a form, just execute JS form.submit() during the click event.
<form id="login">
...
login
</form>
An alternative is to style the button to look like a link with a little help of CSS. This way it'll also work on clients who have JS disabled (for example, the handheld users).
I have a form which is posted to an external API. There is a parameter called customer_token which is passed as an input field. It is used for authentication by the API and every customer is assigned one token. The input field is visible in Firefox's Firebug (even though it is a hidden field).
How do I hide it?
Options
Using javascript as I thought initially
I think using javascript to create that input field at the run time before submitting the form and immediately removing the field will work but still the field will appear momentarily. So, even if a person can't manually get it, I am afraid that a crawler or spider (I don't know the exact term - but some automated script) may get the customer token. Is there a better solution for this? After form submission, the same form remains displayed.
Using one-time token concept as suggested by Ikke
I am not sure how it will work? The API needs the correct customer token value to process any request. So, even to generate a one-time token and return, a request with the customer token has to be sent. This way anyone is able to see my customer token value and they can also send a request to get a one-time token and use it. So how does it solve the problem?
Resolved
Check How to post form to my server and then to API, instead of posting directly(for security reasons)?
Thanks,
Sandeepan
This is not possible. Firebug just reads the DOM in it's actual state, so even if it's added in a later stage, it can still be retrieved.
This way of security is called Security through obscurity and is a kind of non-security. You would have to solve it another way, like letting the server do the request in stead.
You let the user submit the form to the server. Then with curl, you make the call to the webservice with the correct user code.
I don't think this is possible I'm afraid.
Firebug will still see the element if it's inserted via Javascript, as it watches the DOM tree. If this input exposes a security vulnerability then it's the job of your server-side code to validate/fix it.
More details on the API might help somebody answer this question in more detail.
I hope this helps
Hey, I'm just wondering if it's possible to have a form in html do two things on submit, have the action go to a url like normal (for a search) but also run a mysql command.
Thanks!
A form can not run any SQL. HTML has nothing to do with databases, it doesn't know about them, it can't talk to them.
A script on your server can do SQL queries, and that script can be invoked by the browser request. The browser may also submit form data together with the request if it wishes.
It works like this:
User submits form
Browser generates a request and sends it to the given URL
Server receives request, starts up script corresponding to the URL
Script queries database, does something with the received form data
Script outputs some reply
Browser receives reply (website) and displays it
Stop. Never have a client ever run a MySQL (or any database) command. They could do a lot to seriously destroy the integrity of your database. You should have your processing page do the MySQL command after validating the input.
To answer your question, however, it is possible. Your form, upon submit, can call a Javascript function, which in turn does the two actions. But if you're doing this, there's probably some code that needs to be refactored.
I think you have a couple of options here. If your page requires javascript to be enabled for them to submit the form, then you could do an synchronous XMLHttpRequest call before the form submission. If you don't know if Javascript is enabled on the browser or there is a chance that someone can turn it off, then you would need to perform the two actions on the server after they submit the form.