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
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.
One web application has a delete button. Once clicked that web application do GET request first which will return POST form with token key.
Asking Yes or No. if yes, resource is deleted.
How I can achieve this for CSRF attack? I can submit first request hidden in iframe but I need that token to submit second POST request.
Ajax fails due to CORS.
So is it even possible on one page
Send GET request
Parse response and get token
Submit POST form with token to trigger CSRF
I think this is essentially the standard protection against CSRF, a token is generated upon page generation (a GET), and it's verified upon submit (POST) that actually changes application state (deletes an object in your case). So conceptually it looks good to me.
The devil is in the details though. How is the token generated (what algorithm and/or random generator is used, how much entropy it has) and how is it then verified? Is it stored somewhere or stateless? When do you generate a new token and when do you reuse an old one? These are some questions that must be taken into account as always when protecting against CSRF.
One special question that comes to mind for your scenario is whether the confirmation page has all the details about what will be done. A simple "Are you sure?" would not be adequate in your case I think.
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.
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.
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.