On Sep 10, 9:56 pm, Sri sripathikrish...@gmail.com wrote:
If you have built your site correctly, a malicious browser cannot harm
your site.
Vacuously true. In practice there are huge problems if you can't
trust your browser, which you can't.
Lets construct a simple example. Suppose I
Isn't any security that's based on the browser enforcing a policy
essentially a sham?
Or more politely, guaranteed to be ineffective against a deliberate
attack.
The browsers are open source, and the communications channel is
unencrypted,
and you don't have to use a browser at all. There are
make the GWT more secure. so that the evil f**kers won't hack my
site..
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to
Hi Nitin,
Did you recently experience a black hat who hacked your site? If so, you
should post up some details about how the attack occurred and perhaps some
members of the community can make suggestions about how to fix the potential
security leak.
In general, security for web applications,
Thanks for the feedback Shawn and Reinier. I'm not relying on Cookies
at all, the Session ID will be created by the server, it will be a
large pseudo random number. The session IDs will of course expire.
Interesting point about problems that could be created by restricting
access to a single IP,
ERRATUM:
On 4 déc, 10:58, Thomas Broyer [EMAIL PROTECTED] wrote:
Walden, you need a refresh on URIs and HTTP
As Walden pointed out to me in private, I should have directed this
answer towards Jason; as it's quite clear that Walden is aware of all
I said ;-)
The approach I'm taking, and I'm hoping it is a good one, is to divide
the operations on the server cleanly in to read and write. I'm using
php on the server and GWT on the client. The client cannot execute any
write operation on the server without a unique Session ID, the only
way that the
krona: If you are getting the session ID from the cookie, your web
service is still vulnerable to XSRF (wikipedia it). Make GWT send the
session ID in the body of requests (such as a parameter to GWT-RPC or
stuff it in the JSON you're sending to your PHP).
On Dec 4, 1:24 am, [EMAIL PROTECTED]
Also restricting a session to a single IP address can be problematic with
some providers that use web proxies for their clients. I don't know if this
has changed, but years ago AOL made this rather difficult as requests from
clients can be routed out through multiple proxy servers. Individual
I see your point. If the SID is invalid, either via a real attack or by
session invalidation, the result is the same... I don't know who you are so
please re-authenticate yourself. My project is in its early stages, so for
what I thought was an attack I was just throwing an exception to kick
Nah... I need sessions to expire like normal so that those resources can be
released as users leave the site.
On Tue, Nov 4, 2008 at 5:14 AM, ponthiaux eric [EMAIL PROTECTED]wrote:
Did you try to make cyclic call to the server to preserve the session ?
with a Gwt Timer for example .
Jason,
Maybe you could come up with a session-less implementation, so then
you wouldn't have to worry about releasing those resources?
Walden
On Nov 4, 12:52 pm, Jason Vincent [EMAIL PROTECTED] wrote:
Nah... I need sessions to expire like normal so that those resources can be
released as
Jason,
So it's a GET parameter on a POST request? Hmmm. Clever, though.
Walden
On Nov 4, 12:31 pm, Jason Vincent [EMAIL PROTECTED] wrote:
I see your point. If the SID is invalid, either via a real attack or by
session invalidation, the result is the same... I don't know who you are so
Jason,
I think false positives is a feature of this kind of security
strategy, not necessarily a bad thing. How do you handle what you
think is a real XSRF attack? When I use Yahoo (not often), it seems
like it asks me to login a lot. But they smooth the experience with
words to the effect
I have a question about the XSRF protection. I've implemented this
by using a requestFilter which filters for the nocache.js file and
sets a sid cookie with the session id as the value. Then for each
RPC call I send the value of the sid cookie as a get parameter.
When the session is active this
15 matches
Mail list logo
