I'm wondering how the heck you make it impossible for others to change the values and the maxlength by using the source viewer. It causes a lot of trouble for me due to the fact that there is people changing these fields, typing a whole book into these fields. That screws up my database, how to prevent that? Heard something about HTML5, and it should be server sided. But I don't really get it, nor did I find anything about maxlength.
The text is being inserted into a database, and when it is retrieved it gets fucked up because of the lenghts.
You really can't prevent users from messing with the HTML through the browser dev tools.
Which is why you should also validate on the server side as well as the client side. On your code that processes the form post, do validation/sanity checks for all the data, including string length, min/max values etc. Only when the data passes your checks do you allow it into the database.
Depending on your framework/platform, there may be validation libraries that can assist with this.
Related
I am interested in allowing users to "share" information on my website, say something similar to a bulletin board concept. This is something I've never done before because I know that it could introduce security issues.
I'll likely be using ColdFusion as my scripting language. I'm also familiar with PHP, but am leaning towards CF because of its built-in RichText control. The database back-end will either be MySql or SQLServer.
And so, my question boils down to this: What are the specific security issues and how do I screen user input for them? Does the method of SQL storage have any barring (say VARCHAR vs BLOB)?
We actually use a CMS for the primary pages of our site, and the heart of it uses a database vs actual files on the system. So for most of the content on our site, we actually have HTML which is being retrieved from a database.
For example
blurb.body will equal something like '<p>This is a body paragraph</p>'
Then one thing we seem to run into sometimes is a character encoding error. It seems like if someone copies some text into the CMS with a " ' " or something, there isn't anything that will convert it automatically to a '.
But yes, you should be able to do it. Just make sure whatever filtering you do going into the database is reversed correctly on its way out.
Background
I have a (glorified) CRUD application that I'd like to enable HTML5 offline support with. The cache-manifest system looks simple yet powerful, but I'm curious about how I can allow users to access data while offline.
For example, suppose I have these pages for the entity "Case" (i.e. this is CRM case-management software):
http://myapplication.com/Case
http://myapplication.com/Case/{id}
http://myapplication.com/Case/Create
The first URI contains a paged listing of all cases, using the querystring parameters pageIndex and pageSize, e.g. /Case?pageIndex=2&pageSize=20.
The second URI is the template for editing individual cases, e.g. /Case/1 or /Case/56.
Finally, /Case/Create is the form used to create cases.
The Problem
I would like all three to be available offline.
/Case
The simple way would be to add /Case to the cache-manifest, however that would break paging (as the links wouldn't work).
I think I could instead add something like /Case/AllData which is an XML resource, which is cached and if offline then a script on /Case would use this XML data to populate the list and provide for pagination.
If I go for the latter, how can I have this XML data stored in the in-browser SQL database instead of as a cached resource? I think using the SQL database would be more resilient.
/Case/{id}
This is more complicated. There is the simple solution of manually adding /Case/1, /Case/2, /Case/3 etc... to /Case/1234, but there can be hundreds or even thousands of cases so this isn't very practical.
I think the system should provide access to the 30 most recent cases, for example. As above, how can I store this data in the database?
Also, how would this work? If I don't explicitly add /Case/34 to the manifest and the user clicks on to /Case/34 how can I get the browser to load a page that my JavaScript will populate based on the browser's SQL database data and not display the offline message?
/Case/Create
This one is more simple - as it's just an empty page and on the <form>'s submit action my script would detect if it's offline, and if it is offline then it would add it to the browser's SQL database. Does this sound okay?
Thanks!
I think you need to be looking at a LocalStorage database (though it does have some downsides), but there are other alternatives such as WebSQL and IndexedDB.
Also I don't think you should be using numeric Id's if you are allowing people to create as you will get Primary Key conflicts, it is probably best to use something like a GUID.
Another thing you need is the ability to push those new cases onto the server. there could be multiple...
Can they be edited? If they can I think you really need to be thinking about synchronization and conflict resolution hard very hard if that is the case.
Shameless self promotion, I have a project that is designed to handle these very issues, though it's not done, it's close. You can see it (with an ugly but very functional) demo at https://github.com/forbesmyester/SyncIt
I have a editable html5 page and I store new elements in localStorage.
I want to synchronize my page with the server.
I want to know if I can do it without a server side script or if there is some tips to do something like this in a good way.
Thank you :)
You can pull information from the server quite easily using jQuery and then just put it on Local Storage but, if you want to upload local information to the server there is no way around, you have to use some kind of script, tough it's not that difficult, there are many languages (PHP, C#, Python...) and tools you can use.
Keep in mind that when you upload information to the server you have to sanitize it very important security measure.
Basically, the way to go is:
Post the information to the server (using AJAX or a HTML form, either way will do)
Use some server-side script to capture the variables posted.
Sanitize your data (check format, discard non-valid characters, etc)
Store it on database (Do not, ever, concatenate your data with a SQL query ok? that can make you vulnerable to a SQL injection attack), compute something or do stuff.
Return some status to the client (some confirmation maybe?)
You may want to take that confirmation and show a message to the user ("Your info was saved properly" or something like that)
is a javascript timer not sufficient for this manner? or jQuery?
The question really should be more of a problem than a question. If you're updating based on a server's variables then you could use AJAX i believe but if its like increment said variable every X seconds I would focus on using a javascript timer.
I'm hoping this isn't harder than it seems.
I want to create an HTML form with a few text boxes that will allow people to enter in some data and I want these changes to be saved to the form.
For example, if my html page says:
Name: [ ]
...I want someone to be able to click on the [] and enter their name, etc. and click SAVE
and then have the form say:
Name: "Name of Person"
If someone wants to update that, they can click on the person's name and change it and click SAVE and have the HTML form update itself.
How can I do this? I've looked everywhere and people are talking about HTML5 AND PHP. Is it really that complicated to make a simple page like this?
(In case I wasn't clear in my html I'm using the contenteditable="true" option. How can I save those changes?)
I think your question indicates that you don't already know that web pages (including forms) are "stateless", meaning that they do not "automatically" hold or store anything that you do with them. Sorry to disappoint, but as a beginner you will struggle to find "an easy" solution to this.
That is not to say it can't be done - you no doubt see it everywhere - but your level of knowledge misses the fact that you need to actually program the logic to determine how your form will "appear" to store the information and reproduce it on a later visit.
Here's a (really) brief summary:
When your form is used by your user, a couple of things have already taken place before they get to see the form:
the user has requested the page (typing a URL or clicking a link)
the web server has sent the requested page (that is; your website has sent the form)
The next thing that takes place is that your user enters some data on the form. This data is not stored anywhere - if you refresh the page the data is gone, because steps 1 and 2 happen again.
So to avoid this you can use a number of tools:
Javascript: this operates on the user's computer. You can use it to find out if something has been entred on a form, and store it in, for example, a cookie.
Then you will have to build some logic into your page that says, "if my user refreshes the page or comes back to this site at a later date, then look for the cookie. If it exists, then take it's values and pre-fill the form, before the user gets to see it."
Server Side Script: This logic can be built into your web server (using a server side script like PHP) so it actually runs in step 2.
Alternatively you can build it into a javascript function which fires when the page is actually received by your user. This would be a step 3.
A second alternative combines these two ideas (processing on the user side and processing on the webserver side) called AJAX, which basically means that the "discussion" between your javascript and PHP takes place "on the fly" when the data is entered or changed.
And lastly you might want to consider PHP Sessions to store data, and/or a mySQL database. Recently with the advent of modern browsers you now have the possibility to store the information in a local database available to your user's browser...
In all of these cases you will need to learn how these pieces talk to each other, how you retreive the information, and how you update your stateless and static form.
It isn't has straightforward as you might think...
You don't need HTML5. HTML4 is good enough :)
But you need some server side script that saves the changes (on the server side in e.g. a DB or XML file). To make it a better experience (if multiple users use the form at the same time) I suggest you use AJAX to save the changes and poll the server for updates.
This is not complicated (at least I don't think it is), but it seems to be a generation ahead of what you already know. And it could take quite a long time to get the structure in place before you can do this sort of thing without needing help.
There are some basic questions
Does the information need to stay saved when the user hits reload?
Does the information need to stay saved when the user clears cookies?
If the information can be blanked out next time they come back to your page, then it is simple.
Otherwise, we need a way to keep track of which user sees what information, so the guy in Texas does not see the information the guy in Chinatown typed in. Cookies are a common way to do this. You could save the information to the cookies if there is not too much information.
Otherwise, you need sever-side language. This is usually in PHP, but deciding what language has to do with why you want to learn in the first place? Are you wanting to work for a company later on? Do you have your own website?
Please comment to let me know more what is going on, and what the answers are to the two basic questions, and I will better be able to answer.
Usually, for most cases, there is a login name and password (or OpenID), and if cookies are cleared, the user logs in again, but this requires some work to set up a working login before you re-visit this question of how to store what they type.
I was having a discussion with coworkers. We have to implement some security standards. We know not to store 'sensitive, addresses, date of birth' information in hidden fields but is it OK to use hidden fields for your application, in general.
For example:
action=goback
It seems like it would be safer to use hidden fields for that kind of information as opposed to adding it in the query string. It is one less piece of information that a hacker could use against your application.
A hacker can access hidden fields just as easily as querystring values by using an intercepting proxy (or any number of tools).
I dont think there is anything wrong with using hidden fields as long as they aren't used for anything sensitive and you validate them like you would any other value from the client.
Making a field "hidden" has pretty much nothing to do with security, and should be considered a UI decision. Any "hacker" will read your HTML source anyway.
Better to either not show sensitive information at all, or, if you must, to use SSL (to prevent data interception by network intermediaries) and some combination of login challenges (to prevent unauthorized access).
It's only a security hole if you're exposing information that wouldn't be otherwise available to the end user and/or aren't validating it on return.
I'd look instead to storing said information in a server side session variable instead...
Storing your data in a hidden field is, from a security standpoint, exactly the same as storing it in the query string. In fact, if your form uses the GET action, it ends up int he query string anyway.
Hidden fields are completely unrelated to security in any way; they are simply a method by which data can be stored in a form without forcing the user to see it. They do not provide a way of preventing the user from seeing it.
Hidden fields are not always an issue, but they should always ring alarm bells as they have two potential problems:
1) If the data is sensitive, it exposes it to the client (e.g. using a proxy, or simply view source - and it is pointless to try and prevent this programmatically)
2) If the data is interpreted by the server, a knowledgeable user can change it. To take a silly example, if the hidden field contains the user's bank balance, they could use a proxy or some non standard client to make the server think their bank balance is anything they choose.
The second one is a big source of vulnerabilities in webapps. Data associated with the session should be held server side, unless you have a means of validating it on the server (for example if the field is signed or encrypted by the server).
Provided you are sure you're not falling into either of these traps, they can be OK to use. As a rule of thumb, I would not use hidden fields except for data you would be happy to see in the query string, or if javascript needs them for processing. In the latter case, you still need to make sure the server is validating though, don't assume the client will run your javascript.
Consider encrypting the name and value of your hidden field for the purpose of tamper checking since hackers can still get hold of your hidden fields and manipulate them the way they wanted to.
As other people have mentioned both the query string and hidden fields are essentially public data, viewable by the user.
One thing to keep in mind if you place data on the querystring is that people pass urls around, and because of this should never contain any information specific to the current user.
It is also probably a good idea not to include state information in the url, if that state can not be entered directly. Or at least you would need to handle invalid state information in the querystring.
I would say that this is no more or less safe than placing the item in the query string. After all, one could always view source on the site (and there isn't any way to prevent that, since one could always programmatically download the source).
A better solution here would be to encrypt the names of the fields and the values with a key that is generated on the server, and only the server. Unless the server was hacked, the client wouldn't have any clue what the name of the value is, or its value.
Of course, since this is coming from the client, you still have to check the validity of the data coming back, don't just take for granted that it hasn't been altered in a manner that you didn't dictate.
To that end, you will want to use hashing to make sure that the value hasn't been tampered.
In general don't use hidden form fields for sensitive data. Only for static non sensitive POST data that you realise is not safe to handle "as its recieved". The only time i use them is to store Session Tokens as they're rendered and checked upon recieving the POST. To prevent CSRF attacks or atleast make them a great deal harder.
In addition to all the other useful advice by other posters, I'd also add that hidden fields make your app no less vulnerable to SQL injection attacks as url query string values do. As always, sanitise your input.