I'm working on the Java backend for a Flash webgame - the client and server communicate using Action Message Format (AMF). A few weeks ago, another team in our company had their product hacked by a user who decompiled the Flash client, and used an altered version to flood the backend with bogus requests. We want to prevent this kind of attack in our new game.
(More details: webserver used is Tomcat, AMF client is BlazeDS.)
I'd like to know what the best way to prevent this kind of attack would be. Some ideas I had:
the nginx configuration seemed like the best place to handle rate limiting, but I cant find any resources on how nginx interacts with AMF. Do the AMF requests just get sent straight to Tomcat?
most requests involve a userId param for the relevant user. Rate-limiting requests involving overused userIds might be one approach - however, an attacker who just wants to flood the server could easily spam random userIds.
doing the same as above but using IP addresses in place of userIds could work. However, I can't tell if it's possible to get the IP address from an AMF request.
Your Java application should pass unique identifier to the firewall of host operating system and block that client. With this action you would be able to prevent your application from working on things that it isn't supposed to do (being a firewall).
Related
I need to write a server in java that will store integers that are used as stats for my android app. My app has an SQLite database that is already setup that would be useful if I could just pass those contents to the server. I need to do this so that in my multiplayer feature, a player's app will contact the server to know what level their opponent is. (This is not real time). So far I only have a TCP server that opens a client and server socket. Other than that I am not positive what I need to do to make it possible for the server to do what I need. Anyone have suggestions or good tutorials to help me with my problem?
Thanks.
One thing you need to keep track of:
Your SQLite DB has to be used as a player session, until the player logs in as another user. To do this, you have to have one instance of the current logged in player. If you prefer other methods, here's a good list.
I don't think you would need a TCP connection to view the stats, instead implement a REST API in PHP or any other language for back-end that would save, update and look up for a particular player. This is a recommended method. If you are familiar with PHP, this tutorial will give you an idea and full details of what I mean.
Indeed, building a server has many methods. For example, You can use either socket programming or app-server. If you are familiar with web programming, jsp/php/asp.net, you can communicate between your app and server with HTTP requset, which is easy to do.
To be more specific, someone (neme:abc,password:pwd) logging in with your mutiplayer app, when he or she leaves, send the data to server with HTTP request. Then when he or she logging in with other device, you can get the data from status and continues to play. Of course, you can save the data in local with SharedPrefence in Android, too.
By the way, the apache HTTPClient is recommend when using http connection with server.
I was wondering if there is any way to restrict access to my REST webservices for non ios users. I am using Java and Jersey for my RESTful application.
The aim of this exercise is that since my webservice accepts POSTS of XML data, I would like to restrict the exchanges to an iphone client, to prevent manipulation of xml for security reasons.
the client side is an iphone application developed by us.
(moved to answer from comment by request)
No.
The TCP connection from the iPhone is no different than any other. Anything you receive via that connection as an "identifier" (A User-Agent string, for example) can be generated by any other device capable of making a TCP connection.
From your comment:
is there some kind of validation service, where we could check if the device token is an iphone ie the apple device id?
Even if there were ... you now simply have "security by obscurity"; All I need to do on any other device is send a valid id - you can not tell what is sending it.
Strictly speaking, no - as others have said.
However, since
the client side is an iphone application developed by us.
...you can ship a private key with that application, and hope nobody has enough incentive to bypass whatever security Apple has in place and reverse engineer your app to get their hands on that key.
(Note that this 'security' pattern has failed miserably for DVD encryption, console makers, etc... but if your app is confidential enough and the data you're protecting not worth much, it might be good enough for you).
Once you got that key, you can force authentication in your REST service based on some kind of challenge (initial request, 401 with challenge, client sign challenge with private key and send back with request repeat, server verifies with public key).
It may be helpfull if you make a check of user agent in your code like this :
if(request.getHeader("User-Agent").indexOf("iphone") != -1){
//Execute some code
}
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'm trying to implement a Web Anonymizer (like ktunnel) in java, but I really could not get the idea, I need some information about how a web anonymizer works. I really do not need the source or a sample application, just the idea or a tutorial explaining the anonymizer idea.
Thanks.
A basic anonymizer just acts as an encrypted proxy, creating an encrypted "tunnel" between a proxy server and a client, where all traffic from the client goes through the proxy. This accomplishes 3 things:
The client cannot* be determined by looking at traffic between the proxy and endpoint. Hosts on the other end just see the proxy server.
The content of a client's traffic is hidden from monitoring, because the connection to the proxy is encrypted.
It is impossible* to determine the endpoint for traffic originating from the client, because all of it appears to go to the proxy only.
*In reality, a simple anonymizer doesn't provide full protection, because if you look at the amount of traffic between client and proxy, and the traffic between proxy and various sites, you can associate a specific client with their traffic. This is called traffic analysis.
Fancier anonymizers, such as Tor, provide protection against traffic analysis and a lot of other techniques to break anonymity, BUT that's really beyond the scope of the question.
From your point of view, all that matters is writing the proxy software. Your program should be able to create and manage encrypted connections to clients. This means it needs to be able to (securely) initiate an encrypted connection to a host, pass on connections to external hosts, and then pass traffic back and forth. Basically, it needs to act as a router.
There are protocols in place for how to accomplish this -- I suggest you read up on the SOCKS protocol, or Tor. Your best bet if this is a learning project is to write basic SOCKS proxy software. If this is for actual use, there should be libraries in Java that provide the necessary services.
EdiT:
Ktunnel is a less fancy proxy -- it uses a CGI script to redirect information from a URL back and forth. Basically, you enter an address, it fetches the page for that address, and sends it to you. Fairly simple, actually.
I don't know ktunnel, but for basic information about anonymity networks have a look at Tor at wikipedia.
This might be one of those "huh, why?" questions, but I figured it would be worth the try.
How would one, from a server-side application, use the clients IP address as the applications IP address to another website? The basic idea is that any work the server side application does, is seen as the client itself doing the work, and not the servers static IP.
I am not sure if changing HTTP headers would work, but I could be wrong. Is there any documentation out there on this?
Thanks,
Kyle
Utterly, utterly impossible. You won't even be able to open a TCP connection because the other website's server will try to handshake with the client, and fail.
An IP address isn't just any old ID, it's the actually address that servers will send any response to. Spoofing it basically only makes sense if you can fit your request into a single IP packet (which rules out TCP and thus HTTP) and are not interested in the response. Even then it can fail because your ISP's routers may have anti-spoofing rules that drop packets with "outside" IP addresses originating from "inside" networks.
Why on earth would a legitimate application want to spoof its IP address?
Changing HTTP headers might cut it, but most likely it won't. Depends on how naive the other server is.
It sounds like you're trying to do something the wrong way, can you give a bit more information as to what exactly the use-case is?
If there's no processing to be done in between, you can do port forwarding on your server's IP firewall, so the client connects to your server but ends up talking to the other server.
If there's more involvement of your server, then the correct thing to do would be to pass the client's IP to the other server as part of the URL (if it's a web app) or elsewhere in the data (if not) so the receiving server can know and correctly log the process without any need for fakery. Of course this would also call for a change in the other app.
Again assuming we're talking about HTTP, another idea that came to my mind would be to redirect your client to the other server. As long as all necessary data is in the URI, you could advise the client's browser to connect to the other server with a URI of your own creation that could carry whatever extra value your server's processing adds to the request.
Decades ago, the designer of internet asked, "how can we prevent Kyle Rozendo from doing such a devious thing?"
If the client is cooperating, you can install some software on client machine, and do the work from there. For example, a signed java applet on your page. [kidding]If the client is not cooperating, install some trojan virus[/kidding]