I am using survey monkey to allow users to ask users several questions. If they answer the form, they get upgraded to "premium" and are redirected back to the site. There is no code that survey monkey returns that allows me to know that the user actually submitted the form and is not accessing the redirect URL directly. How can I get around this security wise? I want to make sure the user actually submitted the form to qualify for premium. I'm using node.js on the server side and javascript on the client side.
It's not the prettiest solution, but a quick way I noticed that could be possible from the help center is to disqualify respondents. This is because you can set a custom URL to send the user to after you disqualify them which I don't know if you can otherwise.
You can use advanced branching logic to specify when to disqualify the respondent (example, when the last question is answered). You can also use webhooks through the API to get notifications on respondent completions and you can make changes on your end (such as upgrading their plan) using that.
That's one suggestion, you may want to investigate the help center if that doesn't work for you.
Related
I got some of my nifty rails apps working, and its all jiffy and peaceful. I want to secure one tiny part that just feels wrong doing the way it is now - my sign-in procedure, where I use the form_tag with the remote option to send the content of a text and password field for obvious reasons using POST.
Sending a password just plain over HTTP makes me feel dirty. From where I can see, I have the following options:
learn to live with it and hope for the best
learn something awesome to have my controller doing magic through a rails-helper-i-dunno-about trick
build a separate app that runs on HTTPS and make life a living hell by going back to square one.
use JavaScript encryption
Somehow I think my best option is 4 - JavaScript encryption.
However, if the user types in his/her password and it gets encrypted with a part that is server-generated, it should be secure (in relation of solving the problem of sending it in plain text over HTTP) and solve my problem I guess. But on the rails side, to get that to work is to keep (yes, i have many things to cover, still) plain passwords in my database.
I need some help here - some pointers.
Why you should not use option 4: The risk of implementing something wrongly and putting your users at risk is much higher than when using something which already exists.
What you should do instead: Secure your users data by transferring it via https. Put
config.force_ssl = true
into config/environment/production.rb and you are ready to go. (Well and tell the webserver where appropriate certificates are…)
I have a website where your able to advertise things on my website. The problem is that people are able to do it more than once. Is there a way that people are allowed to visit the website and when they join back they will be redirected to another page saying you have already advertised. People are still able to use vpn's but i have a way to stop that.
How can i use javascript or php to record the users ip first when the visit the website, But if they leave the website or reload the page they will be redirected to another page saying you have already advertised. Is this to much work?
Technically yes, you could use JS and PHP to grab a user's IP address and work with it in a database but proxies and dynamic IPs would make it a very easy check to circumvent. You can also use PHP to create a persistent cookie to identify the user and his/her actions and see if you're getting a returning visitor who posted an ad, but cookies can easily be deleted.
So it's not that what you're trying to do is too much work, it's that it's fairly easily circumvented and not very reliable. Your best bet is an authentication system that requires a valid login to post an ad, logging what the advertisers do, and creating logic which will disallow spammy behavior based on your logs.
You won't be able to stop abuses by very, very determined users but you can make it harder and make them think twice about whether it's worth investing all that time and effort into spamming on your site when there are bound to be much softer targets, giving you the time to deal with the most egregious cases personally instead of trying to stop a torrent of spammy ads.
You cannot stop people doing that 100% for sure.
if you block their IPs they use proxy.
if you use session they change their browsers or reset it to default.
if you block their hardware like in facebook block hard disk serial again they use vpn servers.
if ..
there is no way bro.
Ask for paying instead of making it for free.
I've been looking for better ways to secure my site. Many forums and Q/A sites say jquery variables and HTML attributes may be changed by the end user. How do they do this? If they can alter data and elements on a site, can they insert scripts as well?
For instance I have 2 jquery scripts for a home page. The fist is a "member only" script and the second is a "visitor only" script. Can the end user log into my site, copy the "member only" script, log off, and inject the script so it'll run as a visitor?
Yes, it is safe to assume that nothing on the client side is safe. Using tools like Firebug for Firefox or Developer Tools for Chrome, end users are able to manipulate (add, alter, delete):
Your HTML
Your CSS
Your JS
Your HTTP headers (data packets sent to your server)
Cookies
To answer your question directly: if you are solely relying on JavaScript (and most likely cookies) to track user session state and deliver different content to members and guests, then I can say with absolute certainty that other people will circumvent your security, and it would be trivial to do so.
Designing secure applications is not easy, a constant battle, and takes years to fully master. Hacking applications is very easy, fun for the whole family, and can be learned on YouTube in 20 minutes.
Having said all that, hopefully the content you are containing in the JS is not "mission-critical" or "sensitive-data". If it is, I would seriously weigh the costs of hiring a third party developer who is well versed in security to come in and help you out. Because, like I said earlier, creating a truly secure site is not something easily done.
Short Answer: Yes.
Anything on the users computer can be viewed and changed by the user, and any user can write their own scripts to execute on the page.
For example, you will up vote this post automatically if you paste this in your address bar and hit enter from this page:
javascript: $('#answer-7061924 a.vote-up-off').click();
It's not really hacking because you are the end user running the script yourself, only doing actions the end user can normally do. If you allow the end user on your site to perform actions that affect your server in a way they shouldn't be able to, then you have a problem. For example, if I had a way to make that Javascript execute automatically instead of you having to run it yourself from your address bar. Everyone who came to this page would automatically upvote this answer which would be (obviously) undesired behavior.
Firebug and Greasemonkey can be used to replace any javascript: the nature of the Browser as a client is such that the user can basically have it do anything they want. Your specific scenario is definitely possible.
well, if your scripts are public and not protected by a server side than the Hacker can run it in a browser like mozilla.
you should always keep your protected content in a server side scripting and allow access by the session (or some other server side method)
Yes a user can edit scripts however all scripts are compiled on the user's machine meaning that anything they alter will only affect their machine and not any of your other visitors.
However, if you have paid content which you feed using a "members-only" script then it's safest if you use technology on the server to distribute your members-only content rather than rely on the client scripts to secure your content.
Most security problems occur when the client is allowed to interact with the server and modify data on the server.
Here's a good bit on information you can read about XSS: http://en.wikipedia.org/wiki/Cross-site_scripting
To put it very simply:
The web page is just an interface for clients to use your server. It can be altered in all possible ways and anyone can send any kind of data to your server.
For first, you have to check that the user sending that data to your server has privileges to do so. Usually done by checking against server session.
Then you have to check at your server end that you are only taking the data you want, and nothing more or less and that the data is valid by validating it on your server.
For example if there is a mandatory field in some form that user has to fill out, you have to check that the data is actually sent to server because user may just delete the field from the form and send it without.
Other example is that if you are trying to dynamically add data from the form to database, user may just add new field, like "admin", and set it to 1 and send the form. If you then have admin field in database, the user is set as an admin.
The one of the most important things is to remember avoid SQL injection.
There are many tools to use. They are made for web developers to test if their site is safe. Hackbar is one for example.
A lot of my visitors are blind (with it being a site for the blind), and often when trying to diagnose problems, I'd like to know what version of browser etc they're using, whether flash is installed. Because more often than not, someone will swear they are using X, when in fact Y is installed. Currently, I'm using http://jsbrwsniff.sourceforge.net/usage.html piped into an email, but I've got 2 problems here:
First of all, jsbrwsniff is quite "heavy" and hasn't been updated since early 2007, so there's a lot of -1's in the result.
Secondly, if I call it as follows, the page reloads:
Email feedback
And if I call it like this, the page goes blank and looks like it's trying to infinitely load a blank page:
Email feedback
See the nightmare for yourself here:
http://kingston.talking-newspapers.co.uk/
Now, I know there are 1001 articles and comments here and elsewhere saying "don't use browser sniffers, they can be spoofed (etc)", but honestly, you'll have to trust me that this is a significantly useful tool when you're talking someone in their more "senior years" and using a screenreader through "help > about", when they've clicked the wrong window to start with!
I'm using jquery anyway in the site, and I'm aware of $jQuery.browser and $jQuery.support, but these don't tell me the elements I need (like whether Flash is installed, and what version etc). I've looked everywhere for a jquery plugin for my needs, with no luck.
Finally, if I have to stick to the current method of jsbrwsniff then it's not the end of the world, but if anyone knows a way of launching the user's email client populated with the information I need but WITHOUT refreshing or blanking the page, I'd love to know.
BTW - there's a good reason for not using a webform, which is simply because it's easier for the screen-reader user to use an email client they are used to.
Thanks!
Tthat E-Mail should definitely be sent from the server side IMO.
You could make an Ajax request containing all the information you are sniffing to a PHP or other server side script. That script would receive the data and send the E-Mail. It's much more reliable that way.
Other than that, can you emphasize your exact question - is it the sniffing part, or the sending part...?
When the user want's to submit the browser details, you could dynamically create a form (e.g. in a hidden DIV) that contains all the deails you need and inoke the users email client by using a mailto: action URL. For details, see http://www.javascript-coder.com/javascript-form/javascript-email-form.phtml
But I'm not sure how to get the mail automatically sent. That would seem to transcend the security of the browser. So, your users will still have to click send.
Have you considered using mailto: to open the mail client and get the collected information into an email?
I'm not sure if your jquery can format the information you collected into a href link, but if so something like this may be what you're looking for:
mail
I'm working on a website for my county's fair. I want to allow my visitors to be able to ask me questions by inputing their name, email, and comment in a form like this one:
http://lincolnfair.net/images/feedback.JPG
So I guess my real question is how can I send an email (using JavaScript/JQuery) to myself with all these fields as the main body of the email.
You should use a server-side script (e.g. PHP, Python, Perl, etc.). With pure HTML and JavaScript, you can use a mailto form, but this will be very unreliable.
I will suggest uservoice.com , it can integrate with your site nicely, a much more powerful user feedback system, without spending time to code the feedback system yourself
As others have indicated, this is a typical task that can be solved easily using a server-side language. Javascript and jQuery aren't the right tool for this particular problem. To point you in the right direction, use method="post" for your form, and you can access users' submission in a PHP file by examining the $_POST variable. If a <input> element in your form has name="email" in your email, you can access that variable in PHP as $_POST['email']. If you're interested in a PHP solution, look at the documentation for the mail() function.
Jukka has a good guide on How to write HTML forms. It should give you everything you need to produce something functional.
You need a server side component, nothing client side will be a reasonable substitute for that. JavaScript won't help for a form as simple as the one you describe.
The most reliable way will be to use a server side script in your preferred language. The specifics of how to do this are probably outside the scope of this question and would depend upon your language of choice.
Your other option is to set the action of the form as a mailto: which will use the visitors preferred email client to send the email. This will work but is really bad and relies on the viewer having an email client installed and configured.
you can find out more information about the mailto option at http://www.chami.com/tips/internet/010597I.html
Another good option would be a third party site such as www.wufoo.com which handle all of the email business server side for you on their own servers. I believe Wufoo even allow you to embed their forms within your own site.
If you want it to be available on every page, you might want to consider using jQuery and the UI Dialog plugin. You could set it up so that the default feedback is a mailto which gets replaced using javascript with a link that brings up a jQuery Dialog containing the fields you want to collect. This could be submitted back to your server via AJAX and delivered to you via email from the server.
EDIT: Since you've edited your question to indicate a server-side only solution, the above seems somewhat out of context. With others, I would agree that using some client-side code to actually send the email is the way to go (as alluded to above). I think it's preferable to use your own server for this, but I'm sure that you can find many "form to email" services. I would avoid these, unless you want your email addresses harvested for use in SPAM. You might also be able to use a signed applet or ActiveX control for this, again I would not go down that route. As indicated above, I would let the browser handle the interface, but my server handle the sending of the email.
I am not sure i understand your question completely, but if all you want to do is conduct a survey over email, i don't think you need to use jQuery or HTML.
A very simple way to do it is to use the 'Forms' feature in Google Docs.