Re^3: Sending a mail with Perl, nah.. the same and same question...

[MidLifeXis]

in reply to Re^2: Sending a mail with Perl, nah.. the same and same question...
in thread Sending a mail with Perl, nah.. the same and same question...

To reinforce what has been said by Corion and marto: never, ever trust input from the client. Validation done on the client side is only to optimize the input loop by reducing the number of round trips needed to the server.

Assume that you client can (and will if you are really paranoid) put anything on the wire that they wish. I have had to fight the attitude that 'we are not dealing with smart hackers here' when doing code audits (previous life), and was constantly amazed at the lack of concern shown toward basic application security.

[heatblazer]

Thank you, but could you be a little more verbose like giving a really simple example, I am not coding for ages, I learned js, html and perl quite recently and email/web security is something I`ve never heard about, so let`s think we have a mailform, then ajax sending to a perl script which resends to a specific email. What could possibly happen. Example please :)

[ww]

Sorry, but - - for that request.

You've already received numerous tips on the issue... yet now you're asking us to write a tutorial for you?

Consider: you'll learn more by doing your own research... especially if that means getting a grasp on fundamentals, like the language used in the refs already provided.

[MidLifeXis]

Simple example, not necessarily related directly to your script.

Let's say that a password change interface verifies in javascript that the user's password is not blank. What is to stop me from turning off javascript, just issuing the HTTP call directly to your script and bypassing your javascript verification? If you do not check it on the server, you cannot be certain that the data is valid.

In short (as was said earlier), the checks on the server are the important ones. You cannot assume that anything on the client has run. The client needs to be considered completely outside of your control. Javascript is only a suggestion for the browser to run something :-). A telnet client (or netcat, or curl, or...) is all that one needs to reach out and touch your server. The checks on the client side should only be used to improve the user experience.

[heatblazer]

I don`t need a tutorial, just a simple guideline, that was sufficient, I`ll keep in the security direction from now on and stress on serverside instead of js. Thank you all for being verbose here.

[MidLifeXis]

Do not misapply what I was saying. Security is a mindset, not just a bolt-on solution. It is not just a matter of doing validation on the server-side. It is a matter of trust, good programming practices, knowing what code you are running, and a plethora of other things.