I save two versions of user input in the following sequence:
Untrusted user enters raw markdown.
Raw markdown is stored in one table.
A copy of the raw markdown is converted into HTML.
HTML is sanitized and persisted, and is displayed upon request.
The raw markdown version is only displayed when users edit a entry; it's loaded into a textarea of a form.
Is there any risk in loading raw markdown (which could potentially contain unsafe HTML) into a textarea? It would never be displayed outside of a textarea.
I can't sanitize the markdown because it would result in inconsistencies between the markdown and HTML versions I'm saving.
FYI: I always sanitize SQL, regardless of what I'm saving to the DB.
You don't have to sanitize it there, just take care of correctly escaping HTML special characters such as < and >.
For instance, Stackoverflow allows you to post HTML code in your posts, it does not remove anything. This is achieved by encoding, not sanitizing.
It depends how you're "loading" it into the textarea. If you're doing it server-side through simple string concatenation, e.g. in php,
$output = '<textarea>' + $markdown + '</textarea>';
...then there is absolutely a risk, because that markdown could very easily close out the textarea and embed whatever else it wants. If you're using some sort of a component framework (e.g., ASP.NET), then you should be protected as long as you use a safe API method, such as MyTextArea.Value = markdown;.
If you're doing it client-side, it also depends on how you're doing this. You would be safe if you used something like jQuery's .val() setter, but could still expose yourself to XSS vulnerabilities through other approaches.
In short, the general answer is yes, depending on how you're actually creating and populating the textarea.
Are you at least doing SQL sanitation? When you INSERT or UPDATE the data, are you using some type of DAO that escapes the SQL or, if using Java, using a Prepared Statement where you set the arguments?
You must always sanitize things before they go into the DB. Otherwise people could add a stray
'); --Malicious procedure here.
..into a request.
There are some security risks to leaving unsanitized input in the text box; mainly if the user is infected with something that's injecting Javascript, it will show up for him or her each time.
Why even save that? Then you're giving your user a totally inconsistent view from what they enter to what is displayed? They won't match up. It's best to clean the input so when they user views it again he or she can clearly see that the offending HTML was removed for security.
Related
I don't see the benefit of having hidden input? If you set the value of the hidden input why not just use that value at the point where you reference this hidden input?
There are reasons for this but I just don't know them.
They're used to pass data that will be needed when the form is submitted. One of the more common cases would be a form allowing users to edit some existing entry. You'll need to know which entry they're editing so that you can update the correct row in the database when they submit the form. The user doesn't need to edit (or even know) the ID of the entry though, so a hidden field works well here.
Other options
URL parameters:
This could also be done by building the parameters into the url that the form is being submitted to:
<form action="save.php?entry_id=1234">
but this means you have to handle building the URL properly and escaping the data yourself, and the length of URLs servers will accept is limited so it may not work for longer data. So generally using hidden form fields is the easier way to go.
Session variables: When the edit page loads you'd store the entry ID in a session variable, and then retrieve it on the page that saves the changes. That's a lot easier to mess up though; setting up and maintaining sessions may require adding code in several different places, and then their session could expire in between loading and saving, and you have to make sure it works if they have multiple windows or tabs open, and you have to make sure it doesn't do weird things when they hit back/forward. Because of all these potential pitfalls it isn't a great way to solve this problem--passing the id with the data being submitted is a lot more robust.
Cookies: In many languages/frameworks sessions are tracked using cookies, so they're basically the same solution. The pitfalls are the same as for session variables even when sessions are tracked by other methods though.
It sends additional information that the user doesn't know or isn't interested in (such as a security token) so that if the form is submitted twice, you can compare the tokens and reject/accept that submission.
Not using hidden inputs means the server needs to keep track of these values instead. This requires the server to keep state, which could otherwise be embedded into the request (form) itself. This may make the page RESTless (not RESTful), i.e. break the self-containedness of an HTTP request. If you did keep track of hidden values on the server, you would at least need to embed a unique token into each form to deal with several different unique submissions of the same form. The cleanest way to embed such a token is, drumroll, through a hidden input. :)
The Hidden Input field is not displayed on the page, so it does not allow visitors to add anything into it. The Hidden Input allows you, the webmaster, to add specific information to a form, to be passed through the form processor along with the data entered by the visitor.
For example, if you have several forms on different pages on your website, you could use a Hidden tag, in each form, that identifies which page the visitor was on when they filled out the form.
The hidden input is for when you want to send information back on a post without the user seeing the data as a UI element.
The web is stateless - ergo, when a POST comes in, you have only a couple pieces of information to determine what you need to do; Session, Url, some ServerVariables, and the Form data passed to you.
If a piece of data is transient that is not useful for putting in the session, sometimes it is prudent to put into a hidden field.
They can also be useful for storing data on the client side for rich internet applications (such as a product Id that is easily accessible to use in ajax calls).
because you have a php while loop with alot of different objects which you can't get the id's of later and you just save them by storing them in the hidden input... also i like them to be a security check to know my users aren't messing with my post variables through tamper data
If you build a tag system like the one here. You can set the values into a a hidden field.
Consider a form that's being displayed to edit a record in a database, one technique is to bake the id of that record in a hidden input and have it submitted back so the server can read it back.
It's also used frequently for security purposes (as genesis has said).
Another reason might be for javascript-oriented scenarios, perhaps for non standard controls such as treeviews, where the concept of a selected node cannot be represented as a normal input. Instead, JS can manipulate a hidden field and store the node's name/id in it, so that it can be read by the server.
It's just what it's name implies, a form input that is hidden from the user. It's a way of getting data to the server that the user doesn't need to see or control directly. This is especially useful for maintaining state.
I'm working on a project right now where a user creates several items that are represented as data objects in JavaScript and serialized when sent to the server. These data items are expressed one way when displayed to the user with HTML, another way as JavaScript, and a third way when sent to the server. A hidden input is the only way to accomplish this. (Okay, fine not actually the only way, but certainly the most reasonable way).
For example, if you have a form to edit an entity from you data model, you could use an hidden input to place the id of the entity you are updating, since you don't want to have this value put in the text input field to be posted back to the server. the hidden field will be posted to the server as if it were part of your form.
All answers explained why we using hidden inputs in form but here is the security concern.
Security concern
Using hidden inputs in forms can be tampered/changed by View source or using developer tools in any browser.
Solution
Use cryptography in your code/project to avoid changing values in
hidden input by attackers/hackers.
Generic Solution
If you want to store any data in hidden input first encrypt the data and store them in hidden input.
When form is submitted then decrypt them if values not change then save your data.
If changed then show some error or else.
Further reading
Cryptography
Wiki Cryptography
For framework Developers
Other framework developers can find cryptography in their framework.
Cryptography in Laravel(PHP)
Cryptography in .Net
Cryptography in Django
As name implies, Hidden fields are similar to other input fields except one difference i.e, hidden fields are not actually shown to the user and hence can not be edited by the user.Its value can only be set at the time of execution i.e. may be form submitting which posts the data to the server.
But the data set on the html page i.e. name/value can be seen in the html source of the page (view source of the page).
I want to create a php Template in PhpStorm with has a comment block at the top with the usual info (author, creation date, class etc.) but also with a bunch of premade functions.
The purpose of this is that I want to make PHP Unit Class Template with the setup/teardown functions already coded, because these template are used for one project I don't expect they will change as the setups just set global which really should always be set up to make building the test easier (i.e. getting global scoped helpers).
I've tried creating the file templates however when I've copied the code into the template, any variable comes up as in input box when I go to create the file, which might be fine for me using but for someone who's using it for the first time they can screw up by filling in values for this-.
So I am wondering, how can I create a template in PhpStorm which has code in it?
You need to escape $ character which is used by Velocity template engine internally (has special meaning).
You can use ${DS} or \$ for that; so $this will become ${DS}this or \$this .
P.S. ${DS} is a safer choice overall as in some cases \$ may not work.
The official help page has it all explained: https://www.jetbrains.com/help/phpstorm/file-template-variables.html
I'm using SSRS Action -> Go To Url like this:
="javascript:void(window.open('http://xxx/xxx/Pages/ReportViewer.aspx?%2fDevelopment%2fReport&rs:Command=Render&Parameter="& Parameters!Parameter.Value &"'))"
generated link should be:
http://xxx/xx/Pages/ReportViewer.aspx?/Development/Report&rs:Command=Render&Parameter=Úxxx
I need to somehow escape special characters with diacritics like character 'Ú' in example above. Without escaping this character the above link is broken.
Thanks for you help.
You need to URL encode your parameter, however referencing System.Web (as many suggest) is problematic, since later versions of the Reporting Services designer seem to run in a partial trust context, and System.Web does not have APTCA.
Instead, in later framework versions you have the choice of using System.Uri.EscapeDataString or System.Net.WebUtility
See SO question How do you UrlEncode without using System.Web? for examples of both, neither of which require full trust
You need to add Url encoding to your outgoing parameters. This article explains how to reference the library in the report and user UrlEncode() to process your parameters.
I don't see the benefit of having hidden input? If you set the value of the hidden input why not just use that value at the point where you reference this hidden input?
There are reasons for this but I just don't know them.
They're used to pass data that will be needed when the form is submitted. One of the more common cases would be a form allowing users to edit some existing entry. You'll need to know which entry they're editing so that you can update the correct row in the database when they submit the form. The user doesn't need to edit (or even know) the ID of the entry though, so a hidden field works well here.
Other options
URL parameters:
This could also be done by building the parameters into the url that the form is being submitted to:
<form action="save.php?entry_id=1234">
but this means you have to handle building the URL properly and escaping the data yourself, and the length of URLs servers will accept is limited so it may not work for longer data. So generally using hidden form fields is the easier way to go.
Session variables: When the edit page loads you'd store the entry ID in a session variable, and then retrieve it on the page that saves the changes. That's a lot easier to mess up though; setting up and maintaining sessions may require adding code in several different places, and then their session could expire in between loading and saving, and you have to make sure it works if they have multiple windows or tabs open, and you have to make sure it doesn't do weird things when they hit back/forward. Because of all these potential pitfalls it isn't a great way to solve this problem--passing the id with the data being submitted is a lot more robust.
Cookies: In many languages/frameworks sessions are tracked using cookies, so they're basically the same solution. The pitfalls are the same as for session variables even when sessions are tracked by other methods though.
It sends additional information that the user doesn't know or isn't interested in (such as a security token) so that if the form is submitted twice, you can compare the tokens and reject/accept that submission.
Not using hidden inputs means the server needs to keep track of these values instead. This requires the server to keep state, which could otherwise be embedded into the request (form) itself. This may make the page RESTless (not RESTful), i.e. break the self-containedness of an HTTP request. If you did keep track of hidden values on the server, you would at least need to embed a unique token into each form to deal with several different unique submissions of the same form. The cleanest way to embed such a token is, drumroll, through a hidden input. :)
The Hidden Input field is not displayed on the page, so it does not allow visitors to add anything into it. The Hidden Input allows you, the webmaster, to add specific information to a form, to be passed through the form processor along with the data entered by the visitor.
For example, if you have several forms on different pages on your website, you could use a Hidden tag, in each form, that identifies which page the visitor was on when they filled out the form.
The hidden input is for when you want to send information back on a post without the user seeing the data as a UI element.
The web is stateless - ergo, when a POST comes in, you have only a couple pieces of information to determine what you need to do; Session, Url, some ServerVariables, and the Form data passed to you.
If a piece of data is transient that is not useful for putting in the session, sometimes it is prudent to put into a hidden field.
They can also be useful for storing data on the client side for rich internet applications (such as a product Id that is easily accessible to use in ajax calls).
because you have a php while loop with alot of different objects which you can't get the id's of later and you just save them by storing them in the hidden input... also i like them to be a security check to know my users aren't messing with my post variables through tamper data
If you build a tag system like the one here. You can set the values into a a hidden field.
Consider a form that's being displayed to edit a record in a database, one technique is to bake the id of that record in a hidden input and have it submitted back so the server can read it back.
It's also used frequently for security purposes (as genesis has said).
Another reason might be for javascript-oriented scenarios, perhaps for non standard controls such as treeviews, where the concept of a selected node cannot be represented as a normal input. Instead, JS can manipulate a hidden field and store the node's name/id in it, so that it can be read by the server.
It's just what it's name implies, a form input that is hidden from the user. It's a way of getting data to the server that the user doesn't need to see or control directly. This is especially useful for maintaining state.
I'm working on a project right now where a user creates several items that are represented as data objects in JavaScript and serialized when sent to the server. These data items are expressed one way when displayed to the user with HTML, another way as JavaScript, and a third way when sent to the server. A hidden input is the only way to accomplish this. (Okay, fine not actually the only way, but certainly the most reasonable way).
For example, if you have a form to edit an entity from you data model, you could use an hidden input to place the id of the entity you are updating, since you don't want to have this value put in the text input field to be posted back to the server. the hidden field will be posted to the server as if it were part of your form.
All answers explained why we using hidden inputs in form but here is the security concern.
Security concern
Using hidden inputs in forms can be tampered/changed by View source or using developer tools in any browser.
Solution
Use cryptography in your code/project to avoid changing values in
hidden input by attackers/hackers.
Generic Solution
If you want to store any data in hidden input first encrypt the data and store them in hidden input.
When form is submitted then decrypt them if values not change then save your data.
If changed then show some error or else.
Further reading
Cryptography
Wiki Cryptography
For framework Developers
Other framework developers can find cryptography in their framework.
Cryptography in Laravel(PHP)
Cryptography in .Net
Cryptography in Django
As name implies, Hidden fields are similar to other input fields except one difference i.e, hidden fields are not actually shown to the user and hence can not be edited by the user.Its value can only be set at the time of execution i.e. may be form submitting which posts the data to the server.
But the data set on the html page i.e. name/value can be seen in the html source of the page (view source of the page).
What is the best practice to create templates for outgoing email? Should I have each class create the html for the specific email? Should I have a text template with placeholders that are replaced by a common method?
In the first option, I'd have a sendEmail method that takes the formatted html string and send the email. Multiple classes would call this method after creating the html representation of the email.
In the second option, I'd envision having a number of text files like
<html>
<title>{emailTitle}</title>
Your user name is: {userName}
</html>
then a method that takes a hash map of keys, loads the appropriate text file and then replaces each key in the hash map with the value. This seems to have more flexibility as the code doesn't have to know anything about the html to create and you could change the email without changing code (only by removing values - adding a new key would require code changes).
What is the best practice to format email? Is there another option I should consider? I have to send four or five different types of emails - new registration, password reset, order confirmation, etc.
I am using Java, but the question is fairly language agnostic - some languages may make it easier for templating, but I'm asking about normal best practices.
Templates are more flexible because (like you say) your designers can edit them without having to touch the code. More importantly, it enforces a separation between the business logic and the view.
So, this is definitely my preference.