In order to secure Ajax requests, Ran Bar-Zik sugested to "create a small flash file to receive the data, SALT it and encrypt it with MD5. Than sent it to the server. The attacker is able to see the data but it is encrypted." Does anybody who has done this would want to share the code with the world? Thanks :-)
Mr Ran Bar-Zik is mistaken. The security system he has proposed violates CWE-602 and is "(in)security though obscurity".
In short the problem is that the server is providing data to a client side application. The client can do whatever he pleases. He can modify the javascript code or intercept and modify all communications using TamperData or Burp Proxy. A flash application can be decompiled and any secrets stored in memory can be obtained with a debugger like ollydbg. There is no solution to this problem.
Related
I'm working on a mobile client. Dev backend server, I'm working with, isn't stable at all. It may be unusable for a full working day. Prod server is a bit better but still sometimes it doesn't work either. The other problem is it's much more difficult to use it in development. Besides that it's completely wrong to work like that. Basically these servers have been made for web, not for mobile. And it has other strange and annoying thing that destructs me from my primary work - token life time is only 60 seconds. That means if the app didn't refresh the token in that period the token dies. And next time you run the app you need to authorize from scratch. And that process takes centuries(((. May be I just don't understand how it works or something, but as I see web site just spams the sever every minute.
I was thinking how to fix this problem and started using mocking manually. But it's very annoying and time consuming either. The other idea is to use some kind of proxy / cache server that will send request to original server and if it fails return cached data. It seems that it may help in my situation. I'm not sure would such proxy / cache server be able to eliminate token problem. Basically I need to refresh it as soon as first token has been received. But who knows? May be I'm lucky enough?)
So the question: is there some simple to use proxy cache server that I will be able to run locally to achieve what I want?
The other opportunity is to write such proxy server myself. I have no experience in writing servers at all. But as a last chance I could try. The benefit of writing proxy server myself is that I should be able to "fix" token problem for sure. But I don't want to reinvent the wheel.
So any help and thoughts are appreciated.
Not entirely sure if this will solve your problem but let's give it a shot.
I myself have been programming against a rate-limited API. During development I often max out the allowed requests and have to wait before I could continue. I have developed a small caching proxy server that sits between your client and the server. It intercepts the requests and puts both the request and response in it's cache. Whenever it intercepts a request that it's already seen it will respond from cache without forwarding the request to the target server.
I'm not sure what your requests look like. The proxy that I build currently retrieves cache based on URL and HTTP Method, so that may or may not be what you need.
Here's the link to the GitHub repository: https://github.com/RobinvandenHurk/cache-proxy
Disclaimer: For if it wasn't clear, I am the author of this proxy
Some (rogue) ISPs may implement caching on their mobile network in order to reduce traffic on their connections. Some even don't tell their users.
Is there any standard way to defeat all caching mechanism in such cases and get sure to get fresh data when issuing a request on a web server ?
Thanks in advance.
POST requests usually travel unaltered and are not cached, but there's
a drawback to that when you need to investigate server logs and cannot
see query string params in the log. Another popular cache busting
technique is to append a random query string param to each request,
like ?ts=${timestamp}, which forces proxy servers to fetch content
from the origin servers.
In my opinion the best solution for that problems is to use SSL
whenever possible. This makes it impossible for ISPs to tamper with
requests and it is safe to assume that the communication is happening
directly between client and server (and it is possible to detect when
someone tries to hijack the encrypted connection).
Credit to Filip Wasilewski for bringing this to my attention.
I'm interested in having clients, on iOS/OS X platforms using Cocoa, having secure transaction with a dedicated server. I'm looking for the easiest and most 'proper' use of the fancy highly abstracted APIs that Apple has developed. An example of what I'm talking about with those "fancy" APIs is that https is implemented "for free" and could suit my purposes - except that I don't know how to implement the corresponding server portion of that?
The network messages basically need to be a secure session where a client can create an account, or log in with that account, can send a request to the server, and receive a response from the server. The traffic is low volume, latency is OK, most important thing is to implement confidentiality and to make my software effort as short as possible.
The server will be on FreeBSD and will either run Cocoa via Cocotron or can use some other technology you mention that would make development faster. The computation being done on the server is minimal, requires db intfc, etc.
On the client side, NSURLRequest and NSURLConection all support HTTPS mode. You could also try third party libraries such as ASIHTTPRequest.
On the server side, I'm not sure what you mean by "The server will be on FreeBSD and will either run Cocoa via Cocotron". Are you saying that your server will be written in Objective-C and using Cocoa API? I'm not really sure why you want to do something like that. If the code on server is minimal, why not use the Apache server combined with mod_ssl and perhaps PHP to get it done? PHP is excellent for quick and dirty server. You can also use django / rails and other established frameworks (all of which support HTTPS) if those suit your need better.
I want to implement a network level AdBlock/NoScript-like tool for Chromium, but Chromium Extension API can not do much about controlling raw request data.
So here is the idea:
Capture all HTTP queries, and cancel one if URL or MIME matches.
Hand craft packets, like insert a header to an HTTP query.
Can this be implemented by running a thirdparty client making IPC calls to Chromium? A snippet of sample code would be awesome!
(Note: Security is not a problem at the moment coz I only want to try it out for personal interest, not for public distribution. So it may break the sandbox mechanism.)
No it cannot. The Chromium network stack does not support this level of control, neither by Chromium extension, nor by IPC. It's a work in progress. You should watch http://code.google.com/p/chromium/issues/detail?id=50943.
I need a simple way to use XMLHttpRequest as a way for a web client to access applications in an embedded device. I'm getting confused trying to figure out how to make something thin and light that handles the XMLHttpRequests coming to the web server and can translate those to application calls.
The situation:
The web client using Ajax (ExtJS specifically) needs to send and receive asynchronously to an existing embedded application. This isn't just to have a thick client/thin server, the client needs to run background checking on the application status.
The application can expose a socket interface, with a known set of commands, events, and configuration values. Configuration could probably be transmitted as XML since it comes from a SQLite database.
In between the client and app is a lighttpd web server running something that somehow handles the translation. This something is the problem.
What I think I want:
Lighttpd can use FastCGI to route all XMLHttpRequest to an external process. This process will understand HTML/XML, and translate between that and the application's language. It will have custom logic to simulate pushing notifications to the client (receive XMLHttpRequest, don't respond until the next notification is available).
C/C++. I'd really like to avoid installing Java/PHP/Perl on an embedded device. So I'll need more low level understanding.
How do I do this?
Are there good C++ libraries for interpreting the CGI headers and HTML so that I don't have to do any syntax processing, I can just deal with the request/response contents?
Are there any good references to exactly what goes on, server side, when handling the XMLHttpRequest and CGI interfaces?
Is there any package that does most of this job already, or will I have to build the non-HTTP/CGI stuff from scratch?
If I understand correctly, the way I approach this problem would be a 3-tier (Don't get hang up so much on the 3-tier buzz words that we all have heard about):
JavaScript (ExtJs) on browsers talks HTTP, Ajax using XmlHttpRequest, raw (naked) or wrapper doesn't really matter, to the web server (Lighttpd, Apache, ...).
Since the app on the embedded device can talk by socket, the web server would use socket to talk to the embedded device.
You can decide to put more business logic on the JavaScript, and keep the Apache/Lighttpd code really thin so it wont timeout.
In this way, you can leverage all technologies that you're already familiar with. Ajax between tier 1 and 2 is nothing new, and use socket between 2 and 3.
I did not mean that you did not know socket. I just proposed a way to take a desc of a problem where I hear a lots of words: XML/HTML/Ajax/XmlHttpRequest/Java/PHP/Perl/C++/CGI and more and offer a way to simplify into smaller, better understood problem. Let me clarify:
If you want to ultimately retrieve data from the embedded devices and render on the browsers, then have the browsers making a request to the web server, the web server uses socket to talk to the embedded device. How the data is passed between browser and server, that's normal HTTP, no more, no less. Same thing between web server and embedded device, except socket instead of HTTP.
So if just you take a simple problem, like doing an addition of 2 numbers. Except these 2 input numbers would get passed to the web server, and then the web server passes to the embedded device, where the addition is carried out. The result gets passed back to the web server, back to the browser for rendering. If you can do that much, you can already make the data flow everywhere you want to.
How to parse the data depends on how you design the structure of the data that might include container which wraps around a payload.
"... whatever HTTP is coming to the server into usable bits of information, and generate the proper HTTP response"
...but that's not any different than how you handle the HTTP request on the server using your server-side language.
...how to implement a backend process in C/C++, instead of installing a package like PHP
If the embedded device is programmed in C/C++, you are required to know how to do socket programming in C/C++. On your web server, you also have to know how to socket programming, except that will be in that server-side language.
Hope this helps.