I know this topic has been covered from all sorts of angles but I'm not sure I've seen the answer to my specific question.
I am writing a prototype web page in HTML5, CSS, and Javascript. I want the user to be able to browse to a file to attach then attach that file to an email I send to a specific email address I've setup. I don't want the user's default email program to pop up.
I have addresses to SMTP servers within my companies intranet but I don't have access to a server at the moment to put server-side code on. On the web page the user will know email is involved but I don't want them to have to do a thing other than select the file and click a button with no other screens popping up.
I know how to use mailto in order to send an email but I don't think you can use that with attachments.
Is there anyway to do this without having to mess with the server side? Is knowing an smtp server address that I have permissions on enough? Again, this is a prototype but possibly the basis for a new feature on a product.
Thanks!
Is there anyway to do this without having to mess with the server side?
Nope, not unless the target browser has exposes an SMTP client object. (And I don't think any do. That would make spam botnets quite a bit easier to build...)
You need to do this on the server.
Email cant be sent just by client side . You must either use a mailto link if you want it on client side but that's not best way . Instead you should send a request to server and do server side processing .If you have SMTP credential you can send email with server side.
I recently wrote a plugin for PostageApp that lets you send emails through jQuery. Basically, you just have to feed it your API key along with the message payload and you can send it through. With PostageApp, you can add your SMTP servers to the app and send through them.
Usage looks like this:
<script type="text/javascript" src="postage.js"></script>
<script type="text/javascript">
$(function() {
$('p').postage({
apiKey: "API KEY HERE",
recipients: "recipient#email.com",
template: "TEMPLATE_SLUG" });
});
</script>
I didn't publish the plugin because well... it never made sense for production usage because your API key was exposed and that's not a good thing. However, it is decent for prototyping (I use it!) and I would be happy to share.
(Full Disclosure: I am the Product Manager of PostageApp.)
Related
I have a web application that has form based authentication.
the application has registration functionality also. Since last few weeks, i have observed that some users with specific domain is making fake entries into the website and getting the benefits as We do not have any approval workflow.
this user either do it manually or run some script. We thought that we can restrict the registration process as per IP based, however this is not possible to get the visitor exact IP address using C# (please correct if i am wrong).
Can we do it using some other techniques. our requirement is - single registration from a machine per 2 days.
unfortunately I would call this mission impossible.
Idea 1: IP address. The user can use a proxy to register multiple accounts depending on how many proxy he can find (there are a bunch on the internet for free)
OR they could just fake the ip package by putting a random ip in the header. Since all they need is to register so it doesn't matter if the confirmation message was sent to another random guy
Idea 2: one registration per machine. I could fake as many machines as I want with virtual machine and you will have no way to tell from http request.
Alternatively I could just fake all the information with raw http request and I can do that with a script with no issue.
And from what I know you don't have the system right to read hardware id from js (correct me if im wrong)
No method is guarantee to restrict 2 registration per day but IP based method should work against most normal users. Do keep in mind that everyone using the same router could have the same IP (example school, public wifi in apartment)
You could find out the user's IP address within HttpContext object
Whatever your restriction would be - it will be based on the data the browser sends (as long you restrict a specific computer).
Your main desire is to create a "footprint" on that machine in order to use it later - per request.
Whatever your manipulation would be, you should also obfuscate your JS code.
for example, on pageload code you can request for httpheaders dedicated to that machine and save them in cache, then you generate a guid for the client which it suppose to use in order to register.
another option is to use AES to encrypt the data before sending it "on the wire", that way you won't be able to manipulate it.
the most important thing is that once you "drop" a js code on the client he can do whatever he wants, the question is how hard it would be.
**edit:
a more secured way but more complicated that i have once used is creating a sync-key.
an async ajax call to the server requesting an encryption key.
the server call will save the new guid-key in memory and will generate a new one for each request.
you can use this idea to keep track of user debug and browser behavior.
as debuging will hold the code from running the sync key will be change and you can "catch" him.
Neither cookies nor IP can protect against fake entries.
You should look at it from another side. You get unwanted entries and you don't know if it's an automated bot, or spammer, or someone who just doesn't care about your data. Instead of banning entries you should think how to validate them. For example, if you get "aaaaa" as a name and "bbbbb" as an email address - add, at least, regexp validation on client and server side to ensure you get data in a required format. Next level would be to verify the email address by querying the mail server or sending validation email. This will not only help to stop spammers, but also people who doesn't care. If you think it's an automated bot - add a captcha. In case of emergency - ban IP in the web.config (See ASP.Net How to limit access to a particular IP address to a particular page through web.config file (.htaccess similar)?)
I need to put "contact us" form on a static webpage. I want to create the form myself, but I can't send emails from JavaScript. However, I can send HTTP requests. So I want to send request with all the data necessary to some service, and I want this service to send me an email.
I know SendGrid or Mandrill, but I don't want to create a gate for spammers. Obviously, if I used services like this my API-KEY would be publicly accessible in JS files. Unless it is possible to limit this services to send emails only to one address, but I couldn't find such option.
Another options are http://kontactr.com/ or http://www.emailmeform.com but they offer whole web form, and send complicated requests with some ID, which doesn't work when sent again. I.e. I can't forge working request myself. Also, Kontactr comes with captcha, which I don't want and can not remove.
Do you know any simple service I could use? I want it to be as simple as possible - just data in a request which then are sent to my email.
You can achieve this using SendGrid and Parse as outlined in this blog post: https://sendgrid.com/blog/send-email-static-websites-using-parse
Using Parse allows you to keep things like your SendGrid API key a secret.
Additionally, you can make it more spam resistant by adding a Captcha, either something you create yourself, or some of the services out there (reCaptcha, Sweetcaptcha, or others).
I have built a very simple website and paid for my .me domain. I have a simple text form for email addresses and a submit button. I would like to upload the email address to my server once the "submit" button is pressed.
I searched the internet but couldn't seem to find any help doing this. I would like the simplest solution possible. Could anyone direct me to the correct resources? Is this a relatively simple task that can be done with only HTML CSS and JS?
Just using HTML, CSS and JS wont do. You need a way of handling what the user is submitting to your server, some sort of a server side scripting language, PHP, Python, Perl, etc.
Here's a PHP sample
if(isset($_POST['email'] && !empty($_POST["email"])){
$email = $_POST['email'];
// save email address code here...
}
I would like to upload the email address to my server once the "submit" button is pressed.
For what purpose? To create a mailing list? The easiest way to do this is to sign up for an account at something like MailChimp or CampaignMonitor. They give you a simple form to place on your site that allows people to enter their email address and submit it to a database. Then, you log in to that third party service to manage the database, send out emails etc. Works very well.
You could try Windows Azure Mobile Services. Create a table to store the data and then you only need JavaScript, thus avoiding any Server Side tech. This is a paid for service of course but you can get a free trial. https://www.windowsazure.com/en-us/documentation/articles/mobile-services-html-how-to-use-client-library/#create-client
What you can do is not save the information to a file, but save it to a Data Base.
You will need to learn PHP and MySQL (the easiest ones, and there is much tutorials about them)(and probably phpMyAdmin as well).
Look for tutorials, if you don'f find a good one, tell me.
I'm currently writing a twitter client using javascript, then found out many people reminded javascript developers about not revealing "consumer secret". But they never said why.
So why is it so important to hide my consumer_secret? If anyone want to show my "via My_App" on his app, making the name My_App more famous, why should I worried about anything? After all, you can't get any useful information out of my consumer_secret, the user information is protected by both https and token_secret.
A malicious developer could create a spam application using your consumer secret. If enough spam accounts are using the spam app Twitter may disable the entire consumer key at which point your entire application will no longer work with Twitter.
You can think of the consumer secret as a password -- it identifies your client to the server. Anyone with your consumer secret can pretend to be your app.
So you need to keep it secure, and you don't want to "hide" it; you want to encrypt it. This should happen on the server, never in the javascript app that you send to the user.
You can find a lot of helpful information at Google's support page.
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.