I've got two servers, lets call them server 1 and server 2. There is a web application on server 2, that, lets say, shows posts. This application is available on http://www.2.com/showPosts and everybody can access this page. This application also enables to remotely add posts. To do that you have to go to page http://www.2.com/addPost and fill a form.
What I'd like to do is to restrict access to this second page (/addPost) to only one single machine, that is server 1, so that only I can enter this page and fill this form, and everyone else gets 404. How to accomplish that?
edit:
Thank you for your answers. I've done some more reading based on them and now can make my question a little more precise. What I exactly need to do is to authenticate a client by server, whis is the opposite of one-way ssl authentication, where you authenticate a server by a client. I think that any kind of ip based authentication is way too weak and I need some kind of a certificate.
You could use a .htaccess file in the root directory:
<Directory AddPost>Allow from www.1.com</Directory>
This only lets www.1.com access the page. If AddPost is a file, use <Files AddPost></Files>.
Hope this helps!
Protect your http://www.2.com/addPost with a cerificate only present in the Browser on the one single machine.
ServletRequest#getRemoteAddr() returns you the IP of the client that sent the request. You could filter such requests by matching client's IP. For the other clients you can for example redirect to predefined 404 error page.
You can also restrict the addPost address to localhost-only, and establish an ssh tunnel for update purposes.
I suppose you are using Apache Web Server, then you can configure a virtual host and set an access rule to deny from all, allow from server1. Here the documentation.
If it is a Tomcat server you can define a filter in web.xml that will filter request only from allowed source.
Related
I want to support ip based whitelisting in one of the java web-service. To implement that i have written a servlet filter in which i am verifying if the remote-machine-ip belong to the whitelisted ips. To determine the remote-machine-ip i am using the following code :-
String ipAddress = httpServletRequest.getRemoteAddr();
I want to know if there is way by which remote-machine-ip can be impersonated by the attacker without going inside the remote machine. if yes then is there a better secure way to determine the remote ip ?
There is a way, however, it's not an easy way, see this answer for more details.
Remember that httpServletRequest.getRemoteAddr() will be no good if you deploy your app behind a proxy or a CDN. In that case, you'd have to check the X-FORWARDED-FOR header and then it's easy to forge that.
Currently I have got a specific problem finding a solution and I am hoping you are able to provide
some light on the matter.
The Structure of the problem:
The task at hand is to gather a client's login credentials (token) and pass this to the servlet. However I cannot seem to find a good resource to do this. I have researched a wide variety of ways. I.e SPNEGO, WAFFLE etc..., However, these seem to require some sort of active directory by my understanding, I am trying to gather the credentials from the users local machine. A clear explanation or guidance to how I can gather the windows credentials to the servlet for my specific request would be appreciated.
Diagrams are always a better way of explaining so I will provide one if you are still confused:
Windows PC (Client) ------------------------> Java Servlet -------------------------------------> IIS Server
(windows authentication) --------------> (Get Credentials) -------------------- (Check Credentials & Authenticate)
(token) (pass credentials)
Thank you in advanced to anyone who replies, I really appreciate it!.
You are wasting your time. If you only take the credentials from the users local machine then you have no way of knowing if those credentials can be trusted. You might as well just give every user administrative access to your web application.
The reason active directory (or something like it) is required is that it is not under the control of the client and is trusted by the server. For example, when using SPNEGO, the client authenticates itself to the windows domain, the client gets a token from the windows domain that it can only get if it is authenticated, the client passes the token to the server, the server can then validate that token with the Windows domain to confirm that the client is indeed who they claim to be. (Not quite that simple but you get the idea.)
There are other ways to do this - e.g. with PKI - but they all have in common a central, trusted authentication system that the server can use to validate credentials provided by the client.
I'm building an android application which uses a PHP web service (I am building this also).
My question is, how do I prevent unauthorised users using my webservice? For example, could someone get the address of my web service and use it outside of my app (e.g. sending post variables to my service)?
Another related question is how do I prevent spam requests on my webservice? Would it be a case of logging the IP address and limiting the amount of calls?
You can use an HTTPS connection between the Android device and your webservice API endpoint.
Limit you webservice so that it accept only HTTPS connections. You can easily do this using Apache (perhaps using the SSLRequireSSL directive) or directly in your PHP connection handler.
While using an HTTPS transport stream, you can pass specific arguments when making an API call to your webservice to ensure the request has been sent from your application. Nobody will be able to know what specific data are transmitted and will not be able to reproduce an acceptable connection to your remote service.
Regarding your second question, you can indeed limit the number of requests for a given amount of time. Either in PHP or by using specific tools such as fail2ban.
PHP can receive data via POST or GET out of your site and even the internet browser. One of the methods used to do this is by curl.
To what are you referring to this question is known as Cross-site request forgery.
If you are able, you should implement the use of HTTPS in your app and this could solve many security problems.
In case you can not use HTTPS (whether it is expensive or any other problem):
You must verify the information received by POST or GET in your PHP, this language has much ability to solve these "problems"; Take a look at this part of the PHP official documentation.
Suppose you're building a login system:
Also you can add in the login page place a hidden element with secret unique code that can happend only once, save this secret code in session, so, the loging script look in session for this code, compare with what was posted to the script, should same to proceed.
And, if you want to get the IP address of your visitors:
function getRealIpAddr()
{
if (!empty($_SERVER['HTTP_CLIENT_IP'])) //check ip from share internet
{
$ip=$_SERVER['HTTP_CLIENT_IP'];
}
elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) //to check ip is pass from proxy
{
$ip=$_SERVER['HTTP_X_FORWARDED_FOR'];
}
else
{
$ip=$_SERVER['REMOTE_ADDR'];
}
return $ip;
}
Finally, read this.
EDIT
If you can't pay an HTTPS certificate, (as Halim Qarroum says) you can use:
Self signed SSL certificates,
which are free.
Of course this has its advantages and disadvantages
I have java web application to which I'd like to add emailing capabilities, however, I'm unsure what is needed to accomplish this. Specifically I want my app to be able to:
Send emails confirming sign-up
Allow users to send emails to one another, using my app's domain i.e. dan#my-app.com
From my research it seems I'll need a mail transfer agent (MTA) like Postfix and possibly a IMAP server like Courier; but I don't understand the need for the IMAP server.
Thanks.
You need code inside your web app to create and dispatch the email into the SMTP-world. Usually JavaMail is used for this, and you can either enclose it in your web application or (preferred) have the web container provide a correctly configured instance through JNDI. This is vendor specific.
If you do not have a SMTP-server for JavaMail to connect to (frequently this is Exchange for Windows shops), you can either get one running (ask your IT administrator) or use Google Mail or Hotmail or others if it is ok for your web application to send mail through them. It is a bit tricky to use GMail as a SMTP-server, but when set up correctly works very well.
You will need the SMTP-server, as it handles all the boring details regarding MX records and resending if the SMTP-server does graylisting, etc. etc.
Oh, and IMAP is for getting delivered mail, not sending mail. You don't need it.
If it's a Java web app, then the server part is a servlet. Given an email message sent from a client form, your server needs to send that text off as an email.
There's code in the Java EE stack to do this, or you can specifically download JavaMail. This will allow your programs to act as mail clients.
Your MTA receives messages from your servlet and sends them to the users. So far so good.
But you also need a postbox, i.e. the equivalent of a mail in-box for your users. Postfix, QMail and others offer a basic "flat" mailbox model, where mail is simply stored until the client picks it up, and then (usually) deleted. Access is via POP3. IMAP offers a lot more organizational capability, i.e. the ability to specify hierarchies of nested mailboxes, to transfer mails between them and so on. You probably won't want to create a GUI front end to all that complexity, so I'd guess you don't really need an IMAP server. You do, however, want a relatively simple POP3 server to allow your servlet to access the mailboxes via TCP/IP. This is usually part of the "standard" email server packages.
To have your own domain known to the world, you need access to the MX records of your DNS service, i.e. you have to set up one or two of your hosts, on an Internet-facing address, to be your post office.
Finally, if you want to save yourself a lot of trouble, be very careful in configuring your MTA (SMTP server) such that there is no chance for it being used as an open relay. i.e. it should not be possible for your users to send mail to the outside world in general (or hackers will find a way to abuse your Web interface to do this), and mail from the Internet should not reach your users. Most importantly, there should be no way for mail from the Internet to be forwarded to someplace else in the Internet. Find an open relay testing service (they're free) on the 'net and get one to run a test on your configuration once you think you're done.
EDIT:
Looking at Thorbjorn's answer, I realized you probably don't want your users receiving their mail through your app; they probably already have email providers and accounts of their own. In that case, you don't need to worry about inbox capability or a POP3 server. You could consider offering full email services at your domain but that's a very thankless job and if you have any choice, leave that dirty work to GMail, Yahoo, Hotmail and their ilk. Whatever service you provide will never please your customers enough, and you'll be fighting spam and other crime every day.
For starters your server has to have mailing abilities. In linux land sendmail is usually what this will be.
Additionally, check out javaMail.
http://www.oracle.com/technetwork/java/index-jsp-139225.html
i need to send a request to a website when a user submits their url, i tried using curl but it uses server ip which i dont want i have seen a website that is doing a similar job by using applet, users need to open a popup which contains the applet after they leave it open allow it to run it uses a port and then uses the localhost ip like so 127.0.0.1:64653 to send request and basicly curl by the user ip. i decompiled the applet the website was using and they were using java.net.ServerSocket and some other java code but i do not know anything about java. I would to know how this can be done.
I think you are really confused.
a user does not have a URL.
there is a IP address that
represents the browser end of the
connection to the web server he/she
is connected to (actually, there
could be more than one) but this
does not allow something else to
establish a connection to the
browser. So it is not a URL.
the IP address + port number
that the browser has are transient.
In 2 minutes time, the very same
IP/port could denote a different
user, possibly even on a different
machine.
127.0.0.1 is a "special" IP
address that says "this machine".
It cannot be used for communication
with another machine.
notwithstanding all of the
above, web browsers do not accept
incoming HTTP connections from web
servers or anything else. The HTTP
protocol (which is what the web
works on) distinguishes between the
roles of "client" and "server", and
specifies that a client connects to
a server and not the other way
round. A web browser is always an
HTTP client, by convention and also
for security reasons.
So when you say ...
i need to send a request to a website when a user submits their url
... it simply does not make any sense. Please explain what you are tying to achieve ... not how you are trying to achieve it ... and we might be able to help.