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.
Related
I want to create a feedback form where the users input data and when they press submit button, all the data entered is received by the admin at an email address which has been predefined in the code.
i don't want to use "mailto" as it opens another service. Is there any way to send data to email through the HTML form itself?
Forms send data to the URL specified in the action attribute.
mailto: URLs, which you have sensibly ruled out, are highly unreliable.
The only other kind of URL which can be usefully used is an http(s) URL where it is then processed by server side code.
If you want to send the emails to a different address then you need to change the server side code so it doesn't use a single address.
After a lot of research, I have decided to use https://formsubmit.co for this purpose. The details are present in their documentation.
It was exactly what I wanted, and completes my requirements. Thank you to everyone for their help.
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.
Is there a way to include additional request headers in form data, other than action and method? I am hoping to send some authentication credentials cross domain without making the user re-enter their login credentials. ie I want to build an Authentication header directly from form submission.
The domain is SSL enabled, so I considered including credentials in the URL, but as explained here this is a bad idea, as those credentials may be secure over the connection, but can be accessed through the browser by other apps potentially.
Larger Picture
I have access to the cross domain username and password through an AJAX request to the client server (home domain). I want to take those credentials and submit them through a non-AJAX request, so a user can download a document securely without the URL being publicly accessible.
To the specific question, I believe the answer is no - you can't control sending any extra headers from the form itself. There are some other things you can send with a form, but they are not useful to what you want to do: W3 Form Tag Specification
What you could do is do a form POST, which is the standard way to communicate when sessions cookies are out of the question and a query string won't do; just use a hidden field with some sort of token/hash of the credentials. Avoid clear-text of passwords like the plague, and really try to avoid reversible encryption of them too. This is just one of those areas you have to be extra careful to avoid creating an easily exploitable security vulnerability.
But generally speaking it works just fine, and anything that can do an AJAX GET should be able to do an AJAX POST.
I have created hidden form and it will be contain hidden input and javascript submit. But while form is submitted, user can view the source of page and will know all values of it. How can I hide this form or encrypt it so that user can not know values from even source of html.
You could encrypt the data (using standard strong encryption) on the server and store the result in the form.
Standard practise, however, is to not give sensitive data to the client in the first place. Store the data on the server, associate it with a token, then give that token to the client.
Sessions are the standard approach for doing that.
If this information is sensitive, don't post it on the page at all.
Keep the data on the server and have a token to correlate the request with it.
You can't. Maybe you can hide stuff from an average user, but given enough skills data that's available to the user can be read / manipulated by the user. The right practice is to store data at the server and associate it with a user.
For example, you can have a look at PHP sessions.
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