It's a pretty common thing to have to send mails from your app and in most cases it's a real pain in the ... you know where.
So what I'm doing is taking Apache Commons Email (which is based on top of the "official" java mail api) and I'm sending out email in the most simple way there is, i.e. without authenticating to a smtp server. I just do a simple MX lookup on the destination hostname, get the MX servers and try to drop my message at the first one (whether the mail gets rejected or not is a completely different issue and I might sometime soon ask a further question about the whole mess up with return-path: vs. from: vs. reply-to: and the way these headers are (not) handled in java). Back to business... So I've just tried to drop my Message at the mail server with the least preference score.
Here is an example: I want to write to recipient#domain.com. The MX Lookup tells me that domain.com is aware of two MX servers and these are e.g. mail1.domain.com with preference 10 and mail2.domain.com with preference 20. The rfc way to do things is to go to the server with the least preference and drop the mail there. So that's what I do.
And finally my problem: What happens if that server is not available in some way or another? It's pretty simple - I go to the other server, but Apache Commons (and I suspect java mail api) doesn't allow me to do just that. The mail.smtp.host variable is rooted inside the props of the session in the message in the email. And I cannot get at it.
So what's the best way to handle this problem? Should I build my Email completely from the top with the new hostname (mail2), or is there some clever way to make this all work in java without much pain?
It sounds if you are trying to implement a partial mail server, not just merely sending an e-mail. Routing, relaying, caching and delivery retrials are operations implemented and offered by all mail servers and not usually done by mail clients.
What you should do is either use an (one!) existing mail server, which is configured for you to allow relaying outbound mails or if you don't have access to such a server (which I doubt), setup and operate your own server. You then configure this server in mail.smtp.host and forget all you've learned about DNS lookups, server priorities and your worries about what to do if none of the MX servers are reachable.
Related
I am trying to block certain websites using a web application. So, when a I type a url suppose "http://www.google.com" it should first check whether google is blocked by my application or not. If not open the website otherwise reject the browser request to open it. I am unable to find a way to capture all HTTP request from browser so that I can process it.
I Know proxies are the most suitable option but is there any alternative solution to this. After some searching I found a library - jpcap (a network packet capture library) and I was wondering if this could help me or not?
What you are trying to create is a proxy-server.
You have to configure the browser to go through the proxy, then you can deny websites, reroute them etc.
There are many proxies already there (open source and commercial) that offer what you want.
For example: Squid http://www.squid-cache.org/
See Wikipedia description of a proxy here: https://en.wikipedia.org/wiki/Proxy_server
Many firewall products offer the service of a transparent proxy, redirecting all http/https traffic going through the firewall into a proxy server. It seems, you have a direct connection but your packages are really filtered. Aka transparent proxy.
If your assignment does not allow this context, you need to check the assignment again, if you really got the scope of filtering right.
You cannot take over the browser's ip communication from a servlet or servlet filter. Using a (servlet) filter, you can only filter requests directed to your application. One step above, using an application server valve (Tomcat uses this term, others may use a different one), you can only filter requests directed at that server. One step above (or below) your application server is the physical server and the network it is running in.
If your client does not share the same network as your server, you can't even apply transparent proxy to it. Since browsers are running on the client computer, most clients in the world do not share the same network zone as the server.
It just does not work as you expect it.
I have developed myself in the last few months about web development in java (servlets and jsp). I am developing a web server, which is mainly serving for an application. Actually it is running on google app engine. My concern is, although I am using SSL connections, sending parameters in the URL (e.g. https://www.xyz.com/server?password=1234&username=uname) may not be secure. Should I use another way or is it really secure? I don't know if this url is delivered as plaint text as whole (with the parameters)?
Any help would be appreciated!
Everything is encrypted, including the URL and its parameters. You might still avoid them because they might be stored in server-side logs and in the browser history, though.
Your problem seems to go further than Web Server and Google App Engine.
Sending a password through a web form to your server is a very common security issue. See this SO threads:
Is either GET or POST more secure than the other? (meaningly, POST will simply not display the parameter in the URL so this is not enough)
Are https URLs encrypted? (describes something similar to what you intend to do)
The complete HTTP request including the request line is encrypted inside SSL.
Example http request for the above URL which will all be contained within the SSL tunnel:
GET /server?password=1234&username=uname HTTP/1.1
Host: www.xyz.com
...
It is possible though that your application will log the requested URL, as this contains the users password this may not be OK.
Well, apart from the issues to do with logging and visibility of URLs (i.e., what happens before and after the secure communication) both GET and POST are equally secure; there is very little information that is exchanged before the encrypted channel is established, not even the first line of the HTTP protocol. But that doesn't mean you should use GET for this.
The issue is that logging in is changing the state of the server and should not be repeated without the user getting properly notified that this is happening (to prevent surprises with Javascript). The state that is being changed is of the user session information on the server, because what logging in does is associate a verified identity with that session. Because it is a (significant) change of state, the operation should not be done by GET; while you could do it by PUT technically, POST is better because of the non-idempotency assumptions associated with it (which in turn encourages browsers to pop up a warning dialog).
I'm embarrased of how I'm unaware of SMTP / POP3 / IMAP protocols,
as much as I thought I know HTTP and TCP/IP it apears that I took email as granted, and never had to write any piece of code that will do other than sending an email via an existing SMTP server.
My task is to write an incomming email channel and I would like to hear what is the basic aproach
What I need is the ability to listen to a specific email address, and capture the body, subject and attachment of that email for further processing.
I understand you want to programatically recieve mail...use subethasmtp (much lighter and easier than james etc, works very well.
If you want your server to receive e-mails, it's an SMTP server that you need.
(You'll also need to make sure that the e-mail address is set up to be sent to that server, via the MX entry in the DNS.)
Note that, depending on how you want to install this service, you might not need to write an SMTP server yourself (or even use a library). Existing SMTP servers are often capable of delegating the processing of an e-mail to external applications.
You could use somelike Postfix and configure it to use pipe for that address, to send the e-mail to process to the program of your choice (including one that you develop yourself). I'm fairly sure Exim, Sendmail and other MTAs have similar features.
With this sort of configuration, your application would usually need to be able to read the e-mail from the standard input (and have the ability to split/process headers and body), but that's usually much simpler that writing an MTA/SMTP server.
If you really want tighter integration with the MTA, perhaps this could be a good starting point (I've never tried it): http://james.apache.org/
An SMTP server is usually how you'd refer to an outbound mail server; it sends mail.
POP and IMAP allow you to connect to a mail server, to read the mail that's already been received.
You need the receiving/server side of SMTP, and you might benefit from reading up on MTA; mail transfer agent.
You might also be interested in reading about SMTP proxies; so, sent mail would go through your server - and could be filtered/listened to, I suppose - and then get sent further to it's actual recipient.
Use the JavaMail API
I'm developing a server component that will serve requests for a embedded client, which is also under my control.
Right now everything is beta and the security works like this:
client sends username / password over https.
server returns access token.
client makes further requests over http with the access token in a custom header.
This is fine for a demo, but it has some problems that need to be fixed before releasing it:
Anyone can copy a login request, re-send it and get an access token back. As some users replied this is not an issue since it goes over https. My mistake.
Anyone can listen and get an access key just by inspecting the request headers.
I can think of a symmetric key encryption, with a timestamp so I can reject duplicate requests, but I was wondering if there are some well known good practices for this scenario (that seems a pretty common).
Thanks a lot for the insight.
PS: I'm using Java for the server and the client is coded in C++, just in case.
I don't get the first part, If the login request is https, how can anyone just copy it?
Regarding the second part, t This is a pretty standard session hijacking scenario. See this question. Of course you don't have the built-in browser options here, but the basic idea is the same - either send the token only over a secure connection when it matters, or in some way associate the token with the sending device.
In a browser, basically all you have is IP address (which isn't very good), but in your case you may be able to express something specific about your device that you validate against the request to ensure the same token isn't being used from somewhere else.
Edit: You could just be lucky here and be able to rule out the IP address changing behind proxies, and actually use it for this purpose.
But at the end of the day, it is much more secure to use https from a well-known and reviewed library rather than trying to roll your own here. I realize that https is an overhead, but rolling your own has big risks around missing obvious things that an attacker can exploit.
First question, just to get it out there: if you're concerned enough about nefarious client-impersonator accesses, why not carry out the entire conversation over HTTPS? Is the minimal performance hit significant enough for this application that it's not worth the added layer of security?
Second, how can someone replay the login request? If I'm not mistaken, that's taking place over HTTPS; if the connection is set up correctly, HTTPS prevents replay attacks using one-time nonces (see here).
One of the common recommendations is - use https
https man in the middle attack aside using https for the entire session should be reliable enough. You do not even need to worry about access tokens - https takes care of this for you.
Using http for further requests seems to introduce some vulnerabilities. Now anybody with a network sniffer can intercept your traffic steal the token and spoof your requests. you can build protection to prevent it - token encryption, use once tokens, etc. but in doing so you will be re-creating https.
Going back to the https man in the middle attack - it is based on somebody's ability to insert himself between your server and your client and funnel your requests through their code. It is all doable i.e. in case the attacker has access to the physical network. The problem such attacker will face is that he will not be able to give you a proper digital certificat - he does not have the private key you used to sign it. When https is accessed through a browser, the browser gives you a warning but still can let you through to the page.
In your case it is your client who will communicate with the server. And you can make sure that all proper validations of the certificate are in place. If you do that you should be fine
Edit
Seconding Yishai - yes some overhead is involved, primarily CPU, but if this additional overhead pushes your server over board, you have bigger problems with your app
My program needs to download object definitions (basically xml files, maybe binary files) on demand via the net. The program will request objects from my server during runtime. The only thing the program has to send the server is a string that identifies the object it needs (e.g. RedCubeIn3DSpace23). So a basic Key, Value system. My app also has to have some basic authentication mechanism to make sure only legitimate programs access my server’s info. Maybe send the license number and a password.
What is the best way to go about implementing this? I have 0 web knowledge so I'm not sure exactly what technologies I need. I have implemented socket programs in college so maybe that is what I need? Are there frameworks for this type of thing? There could be thousands of users/clients simultaneously; maybe more but I don’t know.
One super important requirement is that I need security to be flawless on the server side. That is, I can't have some hacker replacing object definitions with malicious one that clients download. That would be disastrous.
My first thoughts:
-Set up an ftp server and have each xml file will be named by the key value. Program logs in with its product_id and fixed password and just does downloads. If I use a good ftp server, that is pretty impervious to a hacker modifying definitions. Drawback is that it's very non expandable nor flexible.
-RESTful type system. I just learned about this when searching stackoverflow. I can make categories of objects using URL but how do I do authentication and other actions. Might be hard to program but is this a better approach? Is there a prebuilt library for this?
-Sockets using Java/C#. Java/C# would protect me from overflow attacks and then it is just a matter of spawning a thread on each connection and setting up simple messaging protocol and file transfers.
-SOAP. Just learned about it while searching. Don't know much.
-EC2. I think it (and other?) cloud services add a db layer over it.
That's what I can come up with, what do you think given my requirements? I just need a little guidance.
HTTP seems a better fit than ftp, since you only want to download stuff. That is, you would set up a web server (e.g. Apache), configure it for whatever authentication scheme you need, and have it serve that content.
SOAP is clearly overkill for this, and using raw sockets would be reinventing the wheel (i.e. a web server).
I'd do security on the socket level, using HTTPS. That way, the client will verify the identity of the server prior when establishing the connection, and nobody can intercept the password sent to the server. Again, a decent webserver will support this out-of-the-box, you just need to configure it properly.