The objective is to have a form reflect user's defined constraints on a search.
At first, I relied entirely upon server-side scripting to achieve this; recently I tried to shift the functionality to JavaScript.
On the server side, the search parameters are stored in a ColdFusion struct which makes it particularly convenient to have the data JSON'ed and sent to the client.
Then it's just a matter of separately iterating over 'checkable' and text fields to reflect the user's search parameters; jQuery proved to be exceptionally effective in simplifying the workload.
One observable difference lies in performance. The second method appeared to be somewhat slower and didn't work in IE8.
Evidently, the returned JSON'ed struct was seen as an empty object. I'm sure it can be fixed, though before spending any more time with it, I'm curious to hear how others would approach the task. I'd gladly appreciate any suggestions.
--Stan
Why would you want to do this with JavaScript, if you already have a server-side solution that works with all browsers?
I'm curious to hear how others would approach the task.
I would just do it on the server.
Related
I've got a question which would be applicable to an MVC based platform, but I guess also applicable to any web based platform which handles user form inputs.
What are the best practices, and ideal stage from which to remove trailing/leading whitespace from user input?
I see this could happen at a few stages:
Immediately Upon User Form Input - ala Javascript functions to strip as they type/pre-submission
Inside the Controller on Params Submission
Intermediate Model/Attribute Methods
Prior to or upon Database Persistence
What is best practice in this regard, and specifically the pro's/con's for doing it at a certain stage, or multiple?)
I think it depends on the type of application:
For a standard web app, I would say you definitely want to clean data on the browser sometime before submission so that you can validate it (for ex. an email would fail validation if it has a leading space or a length check). It is better to validate without sending data to the server when possible.
If you are writing an API, especially a public one, I would definitely clean the data server side or return an error. You can't trust clients to send you clean data. I would probably do it in the model before validation which shouldn't be to hard to do automatically.
If bad data can cause a security issue (XSS or SQL injection) then you want to clean it on the server as well as the client. Even on a web app there is nothing stopping a malicious user faking a request from a web browser. If spaces in the data won't break anything then this may not be necessary (if someone 'maliciously' adds a leading space to their blog title it might look weird but it is only going to harm them)
This is a very opinion based question I think. It would depends on the persons who is implementing and also the application.
If you don't have to clean immediately after user input, I would say avoid #1 since it will be confusing to your users while they are typing, and also it can have a performance impact on slower/smaller devices.
#2 and #3 will both be very similar, a nice thing about #3 is that if you're using the same property in many places, your logic for trimming will live in only one place, but both will run on your server which takes away the perf hit from client device.
#4 depending on your DBMS can be very easy or difficult to implement.
I would personally choose #2 or #3, but again that's my opinion and someone else can have a completely different one than mine.
Also you certainly don't need to do it multiple if you get one stage right.
I am trying to code a multiplayer game demo in javascipt using no libraries. Everything is going pretty good, but in order to get better performance to move forward I am going to have to try minimize the data I sent over my websockets or I won't be able to do much. I have been thinking about the best way to do this. I am using Node.JS + Express + Socket.IO.
At first I was sending the keyboard state of all the keys from each client to the server and quickly narrowed this down to true/false values for only the keys I was using. But now I am thinking that I should really be doing something like assigning decimal literal values (0, 1, 3, 4) to each possible input state that are allowed (possible combinations of inputs) and simply sending that value to the server.
I have more experience in statically typed languages such as C++, Java, etc. so I know how I would do this in those languages. But basically want I want to know is if I have a small number of possible input states. What is the best way to send this data using javascript on both ends. It will be going into a JSON object. Is there anyway for me to send a single byte?
https://gist.github.com/1437195 No idea if this works but that could the most optimized solution. I've never played with byteArray. I have no clue if they play well with socket.io.
As far as I read from here, the fact that captchas are not 100% secure.what can be used instead of captcha? As a programmer what do you think? how to solve this issue?
Edit: thanks for all answers.
This is an unsolved problem, and will become more unsolved as time passes. The better the OCR tools get, the smaller the gap between humans and computers, and the harder it will be to tell them apart. Eventually, computers will be indistinguishable from humans, and then the game will be up.
If your server wants to make sure that a human is at the other end of a TCP pipe, there isn't a turing-test in existence that won't eventually be defeated (and there probably never will be one). CAPTCHA is doomed, it's just a matter of how soon.
Of course, that doesn't mean it's all over as far as human authentication is concerned. It just means that automated turing tests, as convenient as they are, won't be an effective way to achieve this for very much longer.
Captcha involving human reflexion (like calculation, really simple question, and the like).
Session tokens
randomly generated hidden input which requires to be null, on the server side generate a random identifier, keep it in a session for a while. If the input is filled and not null, then it might have been filled by a robot, do your users will fill an hidden input ?
I think it really depends on what you are trying to control over the use of captcha.
Further explanation of a suggestion made by Boris:
randomly generated hidden input which requires to be null
The idea is that your form contains several invisible inputs, their type should probably not be set to hidden, but they should be invisible to a human (e.g. set width or height to 0). The initial content of these fields should be empty. If a human fills out the form, the field will be empty, because the human cannot see the field in order to enter anything into it, but if a bot fills out the form the field will (possibly) not be empty, because bots usually just blindly enter something into every field.
Thus, you can distinguish between a bot and a human based on whether the content of this field is empty.
Although captchas can be broken, Capthca's only add to security reCapthca is very good, and a trained OCR like Tesseract is going to have very limited success in breaking it. However, there are outfits that use Human Computation to break them for pennies. But this makes attacks against your system more expensive, and thats the best you can hope for. Cryptography can be broken with brute-force. All password hashes are breakable, but we still use them because it makes it harder for the attacker.
Most of the "solutions" on this thread are "Security Though Obscurity" and you should be wary of these quick fixes to a very complex problem.
Captcha's are used to determine that an actual human being is doing the request, not a machine. Captcha's and captcha-like systems will upgrade, and so will the technology to break them.
So how do you proof that you're talking to a human and not a computer? You could for instance require users to engage in a chat session and have small conversation. There's no AI nowadays that pass the turing test.
So the answer is, no system is perfect. Don't try to solve this issue, but try to find a way to reduce the impact of this.
In the long run government could run openid servers as digital passports for their citizens.
It would be a clean way to identify human beings and prevent sockpuppeting.
At the moment on my website I opted for simple questions. Some questions I've used in the past:
What is two to the power of one?
What is 2+2? (this one was hacked though so don't use it)
What is the name of this website domain?
What is the sum of two and two?
Some other nice ones could be
type in 'stuff' to this box as a spam check
What does 1337 look like? (using only letters)
the current year is?
The best way I can think of is using something unconventional, like a special hidden field that should be null (or another specific value) that robots will mess with.
If some robot maker adjusts his robot for your site, you'll have to quickly change the captcha to something different. It will (hopefully) take a good while before another robot maker adjusts his robot for your site.
Basically, it's a security through obscurity that has to constantly change to remain obscure.
This won't work very well if someone is specifically targeting your site.
Its just an idea, id used that in my application and works well
you can create a cookie on mouse movement with javascript or jquery and in server side check if cookie exist, because only humans have mouse, cookie can be created only by them
the cookie can be a timestamp or a token that can be validate
Gets the coordinates of the mouse, determine whether the coordinates have changed, you can determine whether it is a robot.
Then encrypt the coordinate data.
I am building a webapp to edit some information from a database. The database is being displayed as a table with editing capabilities.
When editing a value, generally I have to validate and do some other tasks, depending on the value that's being edited.
Should I keep a copy as array of objects in memory and use their methods or should I store all the information I need (type of value, id, etc) somewhere in the html table (as attributes or hidden inputs) and get them using several functions?
Which would be best practice?
Is it risky to have many objects stored in memory (taking into account memory usage of the browser)?
storing moderate or large amount of data in memory as objects wont affect the performance with the modern systems. The main factor you should consider is CPU intensive DOM iteration and recurive operations.These takes much of a browser memory.
I preferred to use storing objects in memory rather than HTML hidden fields in many application. It works well and didnt find any performance bottlenecks.
I think you're describing a MVC, and it is considered best practice. However, the memory model of the view would typically be held on the server for security purposes.
It may not matter in your case (and I may be jumping to conclusions), but I would caution against trusting the client with all of the data and validation. You can modify everything in a page in real time with Firebug, so if that puts your app at risk, consider moving your memory model to the server.
whether you will run into memory troubles on client depends on how much data you will be holding at a time. Consider limiting the information returned to a certain number of records and paging through, you can then limit the amount of data to be held in memory or on the page.
I would expect that holding a information in-memory will give a better user experience than requiring constant calls back to a server, or into the DOM. It is probably easier from a programming perspective also
Just do whatever is simplest from a programming perspective. I wouldn't worry too much about memory usage for something like this, unless you're absolutely sure that it's causing problems.
You can address the memory usage of your application later, if and when it becomes an issue.
Most database editing tools e.g. PhpPgAdmin and PhpMyAdmin paginate results and only allow editing 1 row at a time. You can extend that to several without much fuss. As mentioned before remember to paginate.
This is a javascript security question: suppose a page finds out the screen resolution of the computer, such as 1024 x 768, and want to use an AJAX call to log this data into the DB.
Is there a way to actually prevent fake data from being entered into the DB? I think whatever the HTML or Javascript does, the user can reverse engineer the code so that some fake numbers get entered into the DB, or is there a way prevent it from happening totally? (100% secure).
Update: or in a similar situation... if i write a simple javascript game... is there a way for the user to send back the score by AJAX and lie about their score?
If you start with the assumption that the user you are communicating with is malicious, then no; there is nothing you can do to control what data they pass you. Certainly not with 100% certainty - in the worst case, they can use network tools to rewrite or replace any "correct" content with whatever they want.
If you just want to prevent casual maliciousness, you could obfuscate or encrypt your code and/or data. This will not deter a determined attacker.
If you actually trust the real user, but suspect that others might try to impersonate them, you can use other techniques like a dynamic canary: send the user a random number, and if they return that same number to you, you know that it really came from them. (Or you're being hit by a man-in-the-middle attack, but hey; that's what SSL is for.)
It's not possible to stop users from sending any numbers they like back from JavaScript.
I think the best you could do is do some sort of check on the server-side to make sure the numbers sent back look like a realistic resolution.
I'm not sure why someone would spend the time to spoof those numbers in the first place though.
Yes, you are correct. Since you're using client-side code, you have to tell the
user's computer (and thus the user) in one way or another, whatever encryption or obfuscation you're using. There's no way around it.
For the resolution, it would basically be impossible to determine if it's valid resolution. My resolution is usually sent to the server as 5120 x 1600, which seems pretty unrealistic, but it's because the 2 screens are often sent as 1. Otherwise, there is a such a huge variety of possibilities in screen resolutions and screen configurations, you'd probably remove a lot of valid ones, although they might be few.
For the game score, you could do additional checks that make it more complicated to check. Things like sending multiple notices of the score throughout the game and requiring X number to ensure that the score received is valid. (IE, must receive one between 200-300, 400-500, 700-800 and then the final score of 1000.) With the final score, you could also have some kind of encrypted value that can only be used once or that contains some data with a CRC on it. Basically, in the end, require receiving other data than just the score, especially for higher scores.
To attempt an answer by elaborating on comments made by Dok, and yourself, there is a clear distinction between manipulating an application to 'cheat' it out of something, whether it be an online business to get something cheaper or a MMPORG to get more experience, than manipulating it in such a way that it renders the interface incorrectly and diminishes the overall user experience for that particular (hacker?) user.
Your time would be better spent focusing on other aspects of your site. I don't recommend the users of my site manipulate the HTML to make it look funny on their machines, but I'm not going to go all out and obfuscate my server output to stop them from hurting themselves. In your case, range checking against pre-defined safe values, making use of the DB, to ensure the user is viewing with an 'allowed' resolution puts unnecessary burden on your application, and takes time to do.