Develop Reference

Stop Console javascript commands in browser like chrome

I have my website which has this issue. It could be hacked easily through javascript.If the hacker types this in his console he can easily add a user in my database and can signup without going through the stuff like checking password length , checking username length and so on ...
$.post("extra/includes/signup/register.inc2.php",{username:"user1234",email:"email#live.com",p:"here goes password"})
I want a code that could stop him from using console in my website. And if there is no way to do that then how to fix it by some other means ?

Disabling the console won't do. A hacker can always do the same request to your server as you do.
If it is something that isn't public you can protect it using a username and password, looking at the url it is a public script.
If you require a public register script the best way to protect against this kind of thing is to us a captcha (for example recaptcha. It makes it a lot harder to do a scripted attack on your register script.
Always validate the data server side, you can not trust the data you receive from your request because it can be easely manipulated.

You should not rely on client side form validations and it is total bad practice.Try to adapt framework like CI or Laravel . They have particular set of easy ways to validate the form inputs .

Can I Send an Email using ONLY Javascript Without Having to Click The Send Button on the Email Client?

I created a form in HTML and when the submit button is clicked the onclick event calls the following function:
function ProcessSubmition(){
var stringEmailBody=BuildEmailBody();
var stringTo=document.getElementById("SubmittersEmail").value;
var stringSubject = "My Subject Text";
window.location.href = "mailto:"+stringTo+"?subject="+stringSubject+"&body="+stringEmailBody;
}
There are two requirements to my project:
No PHP is allowed on our server.
The person filling out the form must not be able to edit the data which contains a calculate price.
The Problem:
When the function launches, the mail client window appears and displays the message constructed by the function and the user must click the "Send" button in the mail client window.
Unfortunately before the user clicks send, they can simply change the calculated price to a lower dollar amount which obviously is unacceptable.
Is there any way to hide the mail client window and auto-sent? Alternately is there any other method I could use to solve the problem?
Thank you for any help you can give me.

Short answer: No
The JavaScript code that runs in the context of a browser is client-side code that can be manipulated by the end-users. For that reason, you should never rely on client-side code to perform any sensitive operations.
Basically, you will need some server-side support to do what you are tyring to achieve or it will never be secure. Now, if it's dangerous for you that the users can tamper with your code, it would also be dangerous for them if your code could perform tasks such as sending e-mails on their behalf without any form of approval.
Even if you could talk directly to the mail client like you asked and make the email being sent automatically, there's nothing that would prevent users from editing the JavaScript source that generates the message and change the message content.
Alternative? If you will never be able to use any server-side technology, Maybe you could simply send the form details by e-mail and do the pricing calculations in another process afterwards.

How to prevent the clientside user from changing arguments in an onClick function?

I just realized while testing an onClick function with firebug that it would be really easy for a user to change the value of the arguments being passed. This could mess thins up.
Is there any easy way to prevent this, especially when arguments need to be passed?

It is impossible. The code is executing on the user's computer. They are in control.
If they edit it and "mess it up", then that is on their head.
If they edit it and it submits an HTTP request to your server, and your server allows (for instance) that request to delete data belonging to another user then the problem is that your server didn't check that the user submitting the request had permission to delete that data before following through.

You cannot trust anything sent from the client. The user might hand-edit the URL arguments, or a script kiddie could send you a request not even using a browser at all. You must validate everything server-side.

No, this simply can't be done.
Once the script is loaded to the client's machine. He can use/modify it, as he wants.

I'd recommend validating the arguments against expected set of values, and/or business rules wherever the results are being processed (client/server). Ideally validation checks happen on the server where the user has no control. Validation on the client side could even be modified to allow invalid data entry.
There is no way to completely control it - only validate it based on criteria.

You can't prevent this action because JavaScript is a client side . Also you can never trust the client .
You should make a validation for any request at server side to protect your data against client misuse .
you can somehow make it hidden from client eyes
by using .delegate()
EX.
$("table").delegate( "td","click", function() {<br>
// write here your function<br>
});
The client can execute this script but it isn't direct in front of his eyes ..

Can I encrypt content so it doesn't appear in view-source, then show on pageload?

I've got a site where users extend their product trial with a registration code. They click a link (with a key in the URL) from an email, get to this site and a lightbox appears with their registration code. I'm currently displaying the registration code with HTML and hiding it with CSS. Once I check to make sure the URL has the correct key with javascript, I display the registration code. However, this means anyone can just view source on the page and copy the registration code. Is there a way to encrypt the code so it doesn't appear in view source, and then decrypt it if the URL has the correct key? It's one code per product, not per user, so I don't have to do any server side authentication.

If the computer knows it, the user knows it.
You can play obfuscation games, all of which amount to making your Javascript hard to read. But a sufficiently determined user will find it anyway, and once they do, they can easily share it with their friends.
One code per user is the only way to fix this reliably.

I check to make sure the URL has the correct key with javascript
Don't check the key client-side, validate the key on the server.
This is the only way to ensure only valid users get the registration code.
Pseudo PHP example:
if( validateKey($_GET['key']) ) {
echo 'The Registration Code';
} else {
echo 'Error';
}

Client Side Code is inherently insecure. Consider anything you send to a client machine public to the world, and don't trust anything that comes from the client until you cleanse it. A sufficiently determined user will de-obfuscate your code, regardless how much effort you put into the initial obfuscation routine.

Another tip to help you instead to show the registration code in the site you can send back an email to the user with the registration code.
And as Nemo suggest, the right way is one code for user
Hope it help

As mentioned before the client side will not cover your security needs.
Better would be to have the page send a Ajax request to the server containing the key, you can then respond with the registration code.
Even better would be to directly validate the key on the first request, then decide to return an error page or the page with the registration info.

As others have replied, doing this validation server-side is both easier and more secure.
You can have an AJAX request posting the URL key to a php page, that in turn would reply with the correct registration code.
That being said, there is always the possibility of using a client-side use encryption library (like AES), but from what i understand i don't think it would be a good approach to solving your problem.
Again, doing it on the server-side is both extremely easy and as secure as you need.

Encrypt your registration code (plus some magic cookie) with the key in the server before embedding it in your HTML. In your JavaScript, validate the key (which comes in the URL) by decrypting the registration code. If the magic cookie matches, then you get a valid key and you can display the registration code to the user.
View Source will only reveal the encrypted registration code. Without the key, the snooper has no way to extract the registration code.
This means that you'll have a unique key per registration code, which should be the case for your registration system. The key you send to the user in an email, embedded into a link which they click as you said.

What are techniques to get around the IE file download security rules?

Internet Explorer (with default settings, which I generally assume will be in effect on the desktops of the Great Unwashed) seems to dislike the idea of accepting attachment content in an HTTP response if the corresponding request wasn't made directly from a user action (like a "click" handler, or a native form submit). There are probably more details and nuances, but that's the basic behavior that's frustrating me.
It seems to me that this situation is common: the user interface in front of some downloadable content — say, a prepared PDF report — allows for some options and inputs to be used in the creation of the content. Now, as with all forms that allow the user to stipulate how an application does something, it's possible that the input will be erroneous. Not always, but sometimes.
Thus there's a dilemma. If the client tries to do something fancy, like run an AJAX transaction to let the server vet the form contents, and then resubmit to get the download, IE won't like that. It won't like it because the actual HTTP transaction that carries the attachment back will happen not in the original user-action event handler, but in the AJAX completion callback. Worse, since the IE security bar seems to think that the solution to all one's problems is to simply reload the outer page from its original URL, its invitation to the user to go ahead and download the suspicious content won't even work.
The other option is to just have the form fire away. The server checks the parameters, and if there's anything wrong it responds with the form-container page, peppered appropriately with error messages. If the form contents are OK, it generates the content and ships it back in the HTTP response as an attached file. In this case (I think), IE is happy because the content was apparently directly requested by the user (which is, by the way, a ridiculously flimsy way to tell good content from bad content). This is great, but the problem now is that the client environment (that is, the code on my page) can't tell that the download worked, so the form is still just sitting there. If my form is in some sort of dialog, then I really need to close that up when the operation is complete — really, that's one of the motivations for doing it the AJAX way.
It seems to me that the only thing to do is equip the form dialogs with messaging that says something like, "Close this when your download begins." That really seems lame to me because it's an example of a "please push this button for me" interface: ideally, my own code should be able to push the buutton when it's appropriate. A key thing that I don't know is whether there's any way for client code to detect that form submission has resulted in an attachment download. I've never heard of a way to detect that, but that'd break the impasse for me.

I take it you're submitting the form with a different target window; hence the form staying in place.
There are several options.
Keep the submit button disabled and do ongoing validation in the background, polling the form for changes to fields and then firing off the validation request for a field as it changes. When the form is in a valid state, enable the button; when it isn't, disable the button. This isn't perfect, as there will tend to be a delay, but it may be good enough for whatever you're doing.
Do basic validation that doesn't require round-trips to the server in a handler for the form's submit event, then submit the form and remove it (or possibly just hide it). If the further validation on the server detects a problem, it can return a page that uses JavaScript to tell the original window to re-display the form.
Use a session cookie and a unique form ID (the current time from new Date().getTime() would do); when the form is submitted, disable its submit button but keep it visible until the response comes back. Make the response set a session cookie with that ID indicating success/failure. Have the window containing the form poll for the cookie every second or so and act on the result when it sees it. (I've never done this last one; not immediately seeing why it wouldn't work.)
I expect there are about a dozen other ways to skin this cat, but those are three that came to mind.
(Edit) If you're not submitting to a different target, you might want to go ahead and do that -- to a hidden iframe on the same page. That (possibly combined with the above or other answers) might help you get the user experience you're looking for.

There's a whole number of really good reasons IE does this, and I'm sure it's not something anyone would argue with - so the main objective is to get around it somehow to make things better for your users.
Sometimes its worth re-thinking how things are done. Perhaps disable the button, use javascript to check when all the fields are filled out, and fire off an ajax request once they are. If the ajax was successful, enable the button. This is but one suggestion, I'm sure there will be more...
Edit: more...
Do simple submission (non-AJAX), and if the checks fail, send a page back rather than an attachment. The page sent back could contain all the information originally submitted (plus whatever error message to the user) so the user doesn't need to fill out the entire form again. And I'm also sure there will be more ideas...
Edit: more...
I'm sure you've seen this type of thing before - and yes, it is an extra click (not ideal, but not hard).... an "if your download fails, click here" -> in this case, do it as you want to do it, but add a new link/button to the page when the AJAX returns, so if the download failed, they can submit the already validated form from a "direct user action". And I'm sure I'll think of more (or someone else will).....

I have been fighting a similar issue for a while. In my case, posting to a hidden iframe didn't work if my web app was embedded in an iframe on another site (third party cookie issues) unless our site was added to the Trusted Sites list.
I have found that I could break up the download into POST and GET sequence. The post returns a short lived GUID that can be used in a GET request to initiate the download. The POST can do the form validation as well as return the GUID in a successful response. Once the client has the GUID, you can set the src property of a hidden iframe element to the download URL. The browser sees the 'Content-Disposition': 'attachement' header and gives the user a download ribbon to download the file.
So far it appears to work in all the latest browsers. Unfortunately it requires you to modify you server side API for downloading the file.