On Sep 19, 2:39 pm, Sripathi Krishnan
wrote:
> The problem you mention has nothing to do with an unsecured browser. You
> just need to secure your services on the server side, and every servlet
> container has something which lets you do that.
>
> --Sri
I fully agree.
You must also consider that
The problem you mention has nothing to do with an unsecured browser. You
just need to secure your services on the server side, and every servlet
container has something which lets you do that.
--Sri
2009/9/18 ddyer
>
>
>
> On Sep 10, 9:56 pm, Sri wrote:
> > If you have built your site correc
On Sep 10, 9:56 pm, Sri 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 have a web site with a
use
If you have built your site correctly, a malicious browser cannot harm
your site.
Lets say you build a browser that sends out cookies to you. The point
is, you have to first get a real user to actually use your browser.
And there lies the security - you can't get me using your hacked
browser.
If
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 jus
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, built
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 Google-Web-Toolkit@googlegr
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 ;-)
--~--~-~--~~
D'oh! I didn't see this last month.
On 4 nov, 22:03, walden <[EMAIL PROTECTED]> wrote:
> On Nov 4, 12:31 pm, "Jason Vincent" <[EMAIL PROTECTED]> wrote:
>
> > ((ServiceDefTarget) ourInstance)
> > .setServiceEntryPoint(GWT.getModuleBaseURL() +
> > "com.vincent.gwtapp
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,
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 use
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]" <
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 client
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
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 a
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 .
>
> r
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 th
Did you try to make cyclic call to the server to preserve the session ?
with a Gwt Timer for example .
regards.
2008/11/3 Jason <[EMAIL PROTECTED]>
>
> I have a question about the "XSRF" protection. I've implemented this
> by using a requestFilter which filters for the "nocache.js" file and
>
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 t
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 acti
20 matches
Mail list logo
