If I have an html form commented out using <!-- form -->
Which has some input fields that are not sanitized, can someone use those to do bad queries to the db? For example with firebug, can someone remove <!-- and use those input fields to do something nasty?
Depending on the script handling the form, a person can certainly create a local copy of that form without the comments. Indeed, if they know what the input names and semantics are, they can create their own form altogether. There's no good way of detecting whether or not a form submission is from your form or something else masquerading as it.
All the info you send to the user can be modified by him, so if you don't want him to see that info, don't comment it out, just remove it or comment out with php.
And if your database is able to receive 'bad' queries is that something is wrong coded, because an user can post his own data even if you don't send him any form to do so. You have to add server sided security (Authentication, checking user rights, sql injection...) even if your HTML don't allows it, because server side code can't be modified by user.
Not sure, but I'd check it this way: edit the HTML from the browser's element inspector and uncomment it. If then you can use it, you can be hacked.
Related
I have a form built in Kentico and want to change the form action to point to a marketing automation vendor website (eloqua) to process the form. I noticed that there's no way to change the Action on the Form app, so I thought of using js to replace the action dynamically. I'm not sure whether it'll work, but another immediate problem I have is the field name/id generated by Kentico is so long (> 70 characters - e.g. p$lt$ctl02$pageplaceholder$p$lt$ctl03$On_lineForm$viewBiz$Company$txtText) and exceeds the length allowed by the vendor. Is there a way to shorten those names/ids?
To clarify, the reason I need to edit the name because the vendor allows to map (copy/paste) html name to whatever name it's using. I've tried pasting the whole string from one Kentico field and got the error message of exceeding character limit.
First part of the question, how do i direct a form to submit to another site?
In ASP.Net, the only way is to use javascript to alter the 's action url. Since you want to be careful where you edit this, i would use jQuery to replace the "Submit" button on your form with a javascript function that will alter the form before submission (so you don't mess up other postbacks)
$("button.MySubmitButton").click(function() {
$("form").attr("action", "http://TheVendor.com/PostLocation");
});
Next question is to alter the field names. If you absolutely MUST have form element IDs sub 70 characters, you will have to use Javascript again and it will break any postback-related functionality of the elements, so make sure the form is "as is" before doing it.
Again there is security concern because when you post to another location, you are sending ALL the data, including hidden asp.net inputs that contain viewstates and the like. You may want to take the time to 'eliminate' right before you submit any field that you don't want sent to the other site.
Something like this (Test it out a bit first though)
$("input:not(id*='txtName'):not(id*='txtEmail'),select:not(id*='ddlQuestion')").remove();
As #trevor-j-fayas points out, you can use javascript to point a form action to another url. While this does work you may end up writing a lot of javascript to not only point the form to a new url but also to do some data massaging (changing id's, doing url formatting, etc) before sending it to the target.
Additionally you lose some of the benefits of using a Kentico Form because the data never actually gets submitted back to Kentico such as email alerts.
I have worked in a similar scenario where were we sending data to Eloqua but instead of doing it client side we did it from the server by using either:
The OnOnAfterSave event on the BizForm control itself
The global BizForm submit hook BizFormInfo.TYPEINFO.Events.Insert.After
After the form is submitted to Kentico, our custom hook code runs which sends the data to Eloqua. In either hook you can fully access the Form metadata, field names, and submitted values. You can then craft an HTTP POST request and submit it asynchronously using a class such as HttpClient.
Is not a good idea from the architecture stand point and most likely not going to work without opening a huge hole in their vendor web site security. First of all how are they going to process the from if they don't know the field names, what if form fields change etc. Secondly you going to run into hell of trouble trying to submit form one site to another etc. What if the vendor site is not responding etc.
What you need to do is submit the form back to kentico web site i.e. process it on kentico web site and send email notification with results to marketing automation vendor website (the easy way for now) and redirect user to vendor web site.
Redirection and email - you can do out of the box without any programming. Actually to do all the above requires no programming and you get all the information recorded on your Kentico site.
Dear Wordpress developers
I have been unable to find a clear answer to this question, which is inspired by this post by jared about sanitization and this article by Theme Foundation about the Theme Customizer. Particularly, here is a quote from the latter:
If the input is a 1 (indicating a checked box) then the function
returns a one. If the input is anything else at all, the function
returns a blank string. This prevents anything harmful from being
saved to the database.
That last line about preventing harmful things from being saved to the database is something we can all agree to, I guess. But what I don't get is how you can get harmful anything from a checkbox - unless you make programming errors - since there are only two possible values?
So if sanitization in such cases are there to prevent just that: "data corruption" due to programming errors, I don't know if it is a good or a bad thing.
I think it only makes sense to sanitize data when your inputs are text or textfields - at least when protection against harmful stuff is your goal. I get that you sometimes need to format the data to make them useful, but that is a different subject.
That last line about preventing harmful things from being saved to the
database is something we can all agree to
The thing is that "harmful" is very much about context. JavaScript in the database isn't harmful on its own - it is only "harmful" if output to HTML in another user's session. The upshot of it is that this type of vulnerability (XSS) is better dealt with via output encoding. That is, when the content is output to the page then it should be HTML encoded. This would make a script tag be output as <script;> which does nothing more than actually output the literal <script> to the displayed page.
But what I don't get is how you can get harmful anything from a
checkbox - unless you make programming errors - since there are only
two possible values?
Not if an attacker manipulates the POSTed data. For example, if your checkbox is defined as
<input type="checkbox" name="agreeToTCs" />
this would send agreeToTCs=on to your application when checked.
An attacker could manipulate the POST request though and change this to agreeToTCs=evil. This is the equivalent of specifying
<input type="checkbox" name="agreeToTCs" value="evil" />
in the HTML and the box being checked.
Why is it recommended to sanitize Wordpress Customizer select boxes,
check boxes and radio buttons?
All this boils down to is that your application should only be handling valid data. As a quick example imagine a system that lets you select a user level for a new user when creating one. Part of the system design only lets you specify a user equal or lower than yourself. This is to prevent a low level of user from creating an admin account then gaining full privileges. Say if you are logged in as a medium level user the HTML for the drop down may be rendered as follows:
<select name="userLevel">
<option value="low">low</option>
<option value="medium">medium</option>
</select>
and when this is POSTed to the server e.g. userLevel=medium is sent. However, an attacker may be able to manipulate the POSTed data to userlevel=admin and create themselves an admin user. "Sanitizing" the checkbox again on postback makes sure that your application is only accepting valid values.
Is it possible to pass command line arguments using HTTP under Node.js? This seems like a simple thing to do but I can not seem to find out how or if it is even possible. I am struggling a little with the async nature of node so may be missing something fundamental here!
Thanks,
Will
You have a few choices of how to pass state info from one script to another. One of the simplest and most portable has been around since the beginning - when you get the user data posted from page1, send it along in hidden form elements of page2. Then a post of page2 will have the user input on the new form elements and automatically include the hidden form element values as well. Of course you can use the data in the page1 post to otherwise determine what goes on page2. And so on to page3, etc.
The other common choice is cookies. You leave a cookie on the user's browser when they view page1 and then query the browser for it in your code for page2. This is totally portable in modern browsers, but the user can turn off cookies and then it won't work.
Another option is session variables in your node.js scripts. These are pretty easy to work with, but some servers use cookies behind the scenes and they could be off. You might want to read up on that one.
None of those 3 require use of JavaScript on the browser which is required for the Ajax option. In this single page mode you can keep all the state info you want in the JavaScript code because the page never gets reloaded. That gets a little tougher for a beginner and there's also the possibility that Javascript is off. If you are developing a rich, interactive app, you can expect your users to have JS enabled. But for a website with a few pages to sequence to casual visitors it may not always be on.
So, I'd suggest you try the hidden form elements to get started. Something like:
<input type="hidden" name="whatever" value="data-from-page1-post" />
If you put that onto a form in page2, it will come back in the post.
Have fun...
What's is the best way to prevent multiple submission when I'm using XPages?
For "classic web" solution is below.
How to Block Multiple Submissions of the Same Document from the Web
http://www-304.ibm.com/support/docview.wss?uid=swg21089865
Using jQuery, the solution is below.
http://www.norio.be/blog/2008/09/using-jquery-prevent-multiple-form-submissions
But I don't know the way in Xapges. How to prevent it in XPages or Dojo?
It is best not to apply such client-side techniques, because combined with an unreliable internet connection the user may find that the submission fails but be unable to retry.
A much more robust solution is to deduplicate on the server side, which can be done in a variety of ways; these are some that come to mind:
Define the semantics of your form contents so that it doesn't matter if you receive two requests (e.g. if it is updating a record, then a second update just changes nothing).
If you have seen the exact same submission before (compare all the relevant fields), ignore it.
Generate a serial number when you send the form to the client. Don't accept submissions that have a serial number you've seen before — or do something useful; for example, if it is a blog posting or comment form, then a second submission should be treated as an edit to the post created by the first submission.
You can prevent a submit by using XSP.addQuerySubmitListener and return false. This is not the easiest function to get working. So I suggest you take a look at the function in the book 'Xpages Portable Command Guide' or try my project multiple file uploader on OpenNTF. Download the project source code here.
One of our most common error situations in a web application is that a user executes a GET request where the form should have submitted a POST.
I realize that the most likely case is that they got to the page (by way of a POST) and then clicked in the address bar and hit enter.
The question is, are there other less obvious ways that this could happen (print previews/back button, etc)?
We have never been able to consistently repeat the problems. The problems for different users and different pages nor do they happen very often (maybe once a week).
EDIT:
There is no data submitted with the GET request and therefore the processing page crashes out.
I was having a similar issue, although it doesn't sound like this was exactly yours. I had a form that was being submitted via ajax and shouldn't ever use the default submit. Now and then I was receiving errors from a GET done on the form. It shouldn't be possible to submit this form; however, certain versions of Safari for Mac were submitting it on enter. I just added a jquery form.submit() catch on it to prevent the default functionality. I also set the action to a page that wouldn't result in error (in case of lack of javascript).
As you said your problem is intermittent, so having a problem in form method set as get instead of post can be overruled but yes you are right, that if user presses enter in address bar it would be a get request and back button request always depends upon the last request made, if it was a post then any good browser will prompt you about resubmission and if it was get then no prompt, page will be bought back(may be from cache).
May be you can use Firebug (track requests in .net tab)or Fiddler and do some tests with different users/pages if you can reproduce it, its simply pressing enter in address bar.
Edit:
And also get is always supposed to 'retrieve information' so if browser is missing something or need something it will be a get but again check in IIS log for those get requests and try them in browser,if they contains query string for viewstate and eventvalidation, then they are really mis-formed request from post to get, if form method is not explicitly set to get.
I believe that an answer to the question "what are reasons for a browser executing GET rather than POST" does not help to solve the problem of receiving a GET on a form where you expect the a GET. But: To answer that question I would simply say that you receive an GET because the browser sends an GET and you can send a GET on any page where you can send a POST. On the other hand, if the user uses the form the browser sends a POST. Thus your server has to be prepared to handle the GET and it should handle the GET in the same manner as a POST with invalid parameters. My suggestion:
If you receive a GET, display the form again.
If you receive a POST with invalid data, display the form again and notify the user that he has to enter the data in a specific way.
Maybe a trivial answer, but that's what I would do. Don't know if it adds to the discussion.
Wrong, the most obvious reason why you get a GET instead of a POST is that because you're doing a GET instead of a POST.
A less obvious reason is you forgot to specify method="post" in one of your forms. The HTML standard specifies that the default method is GET, so if you want to POST, you must specify method="post" explicitly.
Scrutinize all of your tags and make sure all of them explicitly specify method="post".
EDIT: When you click on the address bar and pressed enter, yes it's true that the browser will GET a page, but your form wouldn't be submitted that way since the browser treats the URL similar to how a copy-pasted URL would be: a new session without any additional information sent to the server (except cookies).