Web Application Security Mode:
(Page 1 of 332)  1 2 3 4 5 6 7 8 9 10 11  Next >
Re: concurrent logins 2014-11-21
Robin Wood (robin digi ninja)
On 19 November 2014 14:27, Aaron Sanders <malmoose37 (at) gmail (dot) com [email concealed]> wrote:
> Just thinking out loud (still haven't had coffee yet) but what about second
> factor? Is that in scope for this question? I would think you can allow all
> the concurrent sessions a user wants as long as all of them were valida

[ more ]  [ reply ]
Re: concurrent logins 2014-11-21
Robin Wood (robin digi ninja)
On 19 November 2014 15:42, Paul Robinson <paul (at) iconoplex.co (dot) uk [email concealed]> wrote:
> On 19 November 2014 10:30, Robin Wood <robin (at) digi (dot) ninj [email concealed]a> wrote:
>>
>> What are peoples opinions on allowing concurrent logins to web apps? I
>> suppose it depends on what the app is used for - forum, admin suite
>> etc - but do

[ more ]  [ reply ]
Re: concurrent logins 2014-11-21
Robin Wood (robin digi ninja)
On 19 November 2014 16:41, Seth Art <sethsec (at) gmail (dot) com [email concealed]> wrote:
> As a user, I love how gmail does it, and I would love to see that more.
>
> As a tester, I personally treat this one as more of a recommendation than a
> finding in most cases. I find this one is difficult to defend in findings
> revi

[ more ]  [ reply ]
Re: concurrent logins 2014-11-21
Robin Wood (robin digi ninja)
On 19 November 2014 18:22, Rogan Dawes <rogan (at) dawes.za (dot) net [email concealed]> wrote:
> You have been logged out, because someone has just logged in using your
> username and password. If this was you, please ignore this message.
>
> Otherwise, please change your password immediately, and contact our security
> depart

[ more ]  [ reply ]
AW: concurrent logins 2014-11-21
Wolfgang Abbas (wolfgang abbas de)
Good points so far!

Additionally, I think in some cases it makes sense to divide internal access to applications depending on the criticality of the application.

For example: I did a hardening of a cms-based extranet for a client of mine. You may log into the system with up to three devices (phone

[ more ]  [ reply ]
RE: concurrent logins 2014-11-21
Nigel Ball (Nigel K Ball dsl pipex com)
Hi,

Not really another option but something that could be added to the options already listed is automatically logging out inactive sessions. How long you wait (minutes / hours / days) before deciding a session is inactive and logging it out would depend on the type of application and security conc

[ more ]  [ reply ]
RE: concurrent logins 2014-11-19
Zaakiy Siddiqui (zaakiy nticon com au)
Hi all,

I'm in favour of Arvind's Option Number 2: i.e., in my way of thinking it: Display to the user the Geolocation of other source IPs that have logged in with the same account.

Need to ensure though that if your users are using 3rd party services to login (common scenario is they use a featur

[ more ]  [ reply ]
Re: concurrent logins 2014-11-19
Seth Art (sethsec gmail com)
As a user, I love how gmail does it, and I would love to see that more.

As a tester, I personally treat this one as more of a recommendation
than a finding in most cases. I find this one is difficult to defend
in findings review meetings, especially given the challenges you
mention, and the pervas

[ more ]  [ reply ]
Re: concurrent logins 2014-11-19
James Wright (jamfwright gmail com)
Hi Robin,

As you said, it depends a lot on what the application is for. If it
is something like email, a user may wish to access it on a computer
and a smartphone, and stay logged into both.

If the web based system requires more security, or is limited by a
license (100 concurrent user limit) or

[ more ]  [ reply ]
Re: concurrent logins 2014-11-19
Matt Konda (mkonda jemurai com)
Robin,

I think youâ??ve hit on the obvious options.

Whatâ??s the business purpose? You might be surprised what the business will and will not tolerate related to this ...

Although it doesnâ??t strictly itself prevent concurrent sessions, Iâ??ve seen people use a two factor system to discourage i

[ more ]  [ reply ]
Re: concurrent logins 2014-11-19
Arvind (arvind doraiswamy gmail com)
I think the best way to do this is to take a quick step back and look
at the risks in each. That's because there's no 1 right answer here as
you already mentioned.

TLDR 1 - There's really only 2 options - you allow it or you dont.
Allowing means anyone can login (more ease of use) and disallowing i

[ more ]  [ reply ]
Re: concurrent logins 2014-11-19
Robin Wood (robin digi ninja)
That is my number 3 but giving a warning when logging them out. Could
still result in a DoS and you'd have to either write very good copy on
the warning or train users what to do when that happens as I reckon
most would just click OK and then log back in again.

Robin

On 19 November 2014 14:14, Rog

[ more ]  [ reply ]
Re: concurrent logins 2014-11-19
DavidMeans833 (at) air-watch (dot) com [email concealed] (DavidMeans833 air-watch com)
It depends upon what the security goals are. As an initial brain-storming
idea generator I consider the problem in terms of the security triad and
determine where and what is the confidential information I need to secure,
what are the integrity vectors, and are there any availability concerns?

I t

[ more ]  [ reply ]
Re: concurrent logins 2014-11-19
Robin Wood (robin digi ninja)
Hi
In theory I like the idea of reporting to the user that the account is
already in use but just think in practice it will be like the broken
SSL cert warning, people just click through it. Maybe not as much in
corporate environments but for home users you'd have to come up with
some very good copy

[ more ]  [ reply ]
RE: concurrent logins 2014-11-19
Martin O'Neal (martin oneal corsaire com)
For us, this is mostly about context. For all sites, some mechanism to report multiple logins back to the user is important for transparency, as is an audit trail entry.

But actually enforcing a single login is only really relevant to applications containing sensitive data.

Martin...

[ more ]  [ reply ]
Re: concurrent logins 2014-11-19
Irene Abezgauz (irene abezgauz gmail com)
Hi,

some thoughts, no particular order.

People use multiple devices, so disallowing concurrent logins is not an
option for most sites.

This obviously depends on functionality. Social communication sites do not
have the same needs as banking apps or nuclear-launch-management-interface
etc.

looki

[ more ]  [ reply ]
concurrent logins 2014-11-19
Robin Wood (robin digi ninja)
What are peoples opinions on allowing concurrent logins to web apps? I
suppose it depends on what the app is used for - forum, admin suite
etc - but do the protections from it add more problems that allowing
it?

Solutions I can see are:

1. Allow concurrent logins
2. Allow concurrent logins but rep

[ more ]  [ reply ]
Re: rating TRACE 2014-11-14
Robin Wood (robin digi ninja)
On 13 November 2014 16:13, Seth Art <sethsec (at) gmail (dot) com [email concealed]> wrote:
> Robin,
>
> If you are lucky, it might be a false positive. I have seen cases
> where OPTIONS tells you that TRACE is supported, but if you try the
> TRACE method, you get a 501 Not Implemented. Worth a try.

You find that a lot with

[ more ]  [ reply ]
Re: RES: rating TRACE 2014-11-14
Robin Wood (robin digi ninja)
On 14 November 2014 11:38, Mike Antcliffe
<mikeantcliffe (at) logicallysecure (dot) com [email concealed]> wrote:
> I completely agree. And one of the biggest problems is that disparity
> between ratings on tests performed by different companies can cause trust
> issues.
>
> Until the entire industry is singing from the same hy

[ more ]  [ reply ]
Re: rating TRACE 2014-11-14
Simon Ward (simon westpoint ltd uk)
On 2014-11-13 16:13, Seth Art wrote:
> If you are lucky, it might be a false positive. I have seen cases
> where OPTIONS tells you that TRACE is supported, but if you try the
> TRACE method, you get a 501 Not Implemented. Worth a try.

For Apache HTTP Server, using the TraceEnable directive it sh

[ more ]  [ reply ]
Re: RES: rating TRACE 2014-11-14
Simon Ward (simon westpoint ltd uk)
On 2014-11-13 11:59, Robin Wood wrote:
> Moving from TRACE to more complex or harder to understand bugs just
> makes this worse and more subjective. I wish I could suggest a way to
> fix it so everyone was rating based on the same levels. I know some
> people aren't optimistic about CVSSv3 being abl

[ more ]  [ reply ]
Re: rating TRACE 2014-11-14
Simon Ward (simon westpoint ltd uk)
On 2014-11-12 16:19, Robin Wood wrote:
> I've always given TRACE enabled a rating of low in my reports and I
> know other testers who don't even bother reporting it but a client has
> asked for a CVSS score for it and in Googling I found that Rapid 7
> rate it as a 6.0, that is high end of medium.
>

[ more ]  [ reply ]
Re: rating TRACE 2014-11-14
Simon Ward (simon westpoint ltd uk)
On 2014-11-14 13:41, Simon Ward wrote:
> The impact should really be none, since there is none if you can't
> manipulate the browser or plugin to create your dodgy request in the
> first place. If we're treating it as a vulnerability and fudging the
> CVSS scores for it then I might give it a partia

[ more ]  [ reply ]
Re: rating TRACE 2014-11-14
Manolis Mavrofidis (mmavrofides gmail com)
I'm going to be a little bit off topic.
The problem with TRACE, and other low-rated vulnerabilities, expands
beyond the ratings because you never know how an attacker is going to
use TRACE or any other vulnerability to escalate his attack vector.

On 13 November 2014 18:13, Seth Art <sethsec@gmail.

[ more ]  [ reply ]
Re: rating TRACE 2014-11-13
Seth Art (sethsec gmail com)
Robin,

If you are lucky, it might be a false positive. I have seen cases
where OPTIONS tells you that TRACE is supported, but if you try the
TRACE method, you get a 501 Not Implemented. Worth a try.

Seth

On Wed, Nov 12, 2014 at 11:19 AM, Robin Wood <robin (at) digi (dot) ninj [email concealed]a> wrote:
> I've always given

[ more ]  [ reply ]
Re: RES: rating TRACE 2014-11-13
Martino Dell'Ambrogio (tillo tillo ch)
This happens with any vulnerability and it's the reason we use our own
rating system, expose all of the variables to the customer and
eventually discuss scale changes or exceptions according to their
security model.

Most rating systems are flawed because they try to cover all situations,
but situat

[ more ]  [ reply ]
Re: RES: rating TRACE 2014-11-13
Robin Wood (robin digi ninja)
The general consensus seems to be low, apparently a QualysGuard
scanner (which is ASV approved I've been told) rates it as
informational and some, like Vivir rate it as medium.

Such a simple issue and such a wide discrepancy of reporting levels
all with their own justifications. Makes me feel sorry

[ more ]  [ reply ]
RES: rating TRACE 2014-11-12
Fábio Soto (fabio andradesoto com br)
I'm rating it as low, and double check it, because it's commonly a false-positive.

-----Mensagem original-----
De: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] Em nome de Robin Wood
Enviada em: quarta-feira, 12 de novembro de 2014 14:19
Para: webappsec (at) securityfocus (dot) com [email concealed]
Assun

[ more ]  [ reply ]
RE: rating TRACE 2014-11-12
Kenneth Kron (kenneth kron truvantis com)
Regarding PCI scanning. There are quarterly scans (ASV) that will absolutely be a fail if trace is enabled. I think this is correct as there is really no functional value to giving the user all of this detail and

You are providing a very detailed map to you attack surface.

Other interim scans

[ more ]  [ reply ]
Re: rating TRACE 2014-11-12
Robin Wood (robin digi ninja)
On 12 November 2014 22:24, Andrew van der Stock <vanderaj (at) greebo (dot) net [email concealed]> wrote:
> Once you plug in the rest of CVSS and get past the base score, it turns out
> it's CVSS rating 1.0, which where I believe it to be.
>
> CVSS v2 Vector
> (AV:N/AC:M/Au:N/C:P/I:P/A:N/E:POC/RL:OF/RC:C/CDP:N/TD:L/CR:ND/IR:L/A

[ more ]  [ reply ]
(Page 1 of 332)  1 2 3 4 5 6 7 8 9 10 11  Next >


 

Privacy Statement
Copyright 2010, SecurityFocus