We experience session bugs in our SCA website (Mont Blanc).
The session bugs are:
you are logged in but sometimes the website still shows the 'login | register' link. Ie, it doesn't recognise you as logged in.
you click the login/register link intending to login but you get taken to the checkout page
Have other SCA developers experienced this bug (SCA is known for many) and what have you done to fix this? Any advice would be very much appreciated.
Yes, It is there, We are changing our version to Elburs
Being sent to checkout upon logging in is due to the SSP application's touchpoints missing parameters. Specifically, the checkout.ssp is used for login, checkout, and register. By default, it handles checkout, but with a parameter of is=login or is=register, it will go to the appropriate places after login is complete.
I'm not sure offhand the solution for the first question.
Related
For many applications that I've ever worked on. After logging successfully and session's still active, if users try to access signin/signup page by directly using browser address bar, they'll be redirected to dashboard or home page. I just follows some existing applications such as Goolge perhaps.
But what's the main reason of this flow? Does it raise any security risks if users can still access signin/sigup while their sessions are still active?
The decision to have separate login page or redirection of user to another page depends on the use case or requirement that you have for your website. It is directly related towards the functionality you want to provide to users.
It is mainly for bringing functional separation such that the login page is specifically for logging in and dashboard page or home page is to show the the account details or other related information of your home page. It also can be used for security purpose.
Functionally, having user login and dashboard page on same page can have its own challenges based on the other processing that is being done by you as per your use case. Consider a scenario where an email shall be sent whenever you login and also some additional processing is done based on the login procedure. Each refresh on the posted page would log the user back in. In such a case, every refreshment of the dashboard page would trigger an email and also does additional processing which may not be desired. In the perspective of security, based on your requirement, you may redirect URL based on PRG(Post-Redirect-Get) pattern to a restricted page or guest user page rather than having the main home page when an unauthenticated user logins or based on the subscription type of user.
It should also be noted that having a login mechanism integrated into the main page also has an advantage based on your website requirement as it provides the ability to login without losing the context of what the user is doing which is purely dependent on the requirement for your website. However, a separate login page has the advantage of being easier to implement and also for the pages that have sensitive information, you can simply redirect to the login page, rather than having to worry about rendering UI without the context of a valid session.
This is more of a usability feature than a security one. Developers put a bit of additional effort to implement stuff like this. Here is an example how they do it.
You should probably look into "OAUTH2" or similar authorization (beware not authentication) software, that might spread the light its about tokens and who might use them where and when. (pretty shady that's why im gonna leave that link here but you should really dig deeper for yourself)
https://docs.apigee.com/api-platform/system-administration/using-oauth2
In our website, we are displaying a change password link which redirects user to "https://account.activedirectory.windowsazure.com/ChangePassword.aspx", where user will be able to change the password.
On successful change password, we need a way to redirect user back to our application. Currently it is redirecting user to "https://account.activedirectory.windowsazure.com/profile/default.aspx".
Any help or hint is appreciated.
This is the default behaviour and currently this is not possible. There is already a similar feature request on feedback.azure.com where you can suggest new features, enhancements or bugs.
If you would love to see this feature you can upvote this feature -> http://feedback.azure.com/forums/169401-azure-active-directory/suggestions/7156218-redirect-new-users-to-application-not-manage-wind
My experience is that they are actively looking at these features and also implement them (when enough users request them).
I am working on a financial web application.
There is a client requirement that if user is logged in and already browsing the app. If he copies and pastes the browser url to another window. In another window, the user should get logged out.
I know http is stateless and there is no inbuilt browser mechanism (cookies etc) to solve it, this needs to be implemented by programming only. I guess people have already solved this problem. Do you know know possible solution to solve this issue?
Sadly, there is no solution.
The browser keeps the cookies and all of the user informations for all the Tabs & Windows you open. It will clear the datas (like cookies that ask to be removed after the session) as soon as you close ALL tabs and windows of your browser. Note that if the user use another browser, the behaviour your want will be respected — browsers dnn't (yet ?) share this kind of informations.
It is simply not possible to solve the problem with code, and you'll have to find work-around.
As a researcher, I've seen one of these solutions : de-auth the user on the HTTP_REFERER (Apache Env. Variable). As soon as the referer was not the application itself (except for the login form), the user was de-authed. But take care of it : the Referer is an info sent by the browser. And no information sent by the browser should be trusted :). The advice remains, if only you want to use Javascript. You'll find someone to use a JS-disabled-browser to bypass your verification.
That's why Application Development is not yet dead ;)
Cheers.
K.
We have a Magento store and sometimes when users login it authenticates with someone elses user information.
When the user goes into my account they can see the order details of another customer.
I have found a forum that said to activate the Validate HTTP_USER_AGENT and Validate REMOTE_ADDR values under the Session Validation settings but we are still seeing the issue.
Does anyone have any ideas of what may be causing this issue?
Thanks in advance for your assistance.
George
I never really took the time to properly debug this, but some time ago we had an almost identical problem. Eventually it looked like that when System > Configuration > Web > Use SID on Frontend is enabled and you also have Magento Enterprise Full Page Cache enabled it sometimes saved the SID within cached templates. When other users clicked the link with the incorrect SID they sort of took over that session.
After disabled the SID option, we never had the problem again.
Perhaps not a real answer, but maybe valuable information for you.
I am trying to test a webpage using Nessus. I have tested all the stuff about the Server. But now I want to proceed by login to the webpage and test all possible pages behind the login form. But I couldn't achieve it. I gave all(text, password and hidden fields) the form fields' values including the ticket generated by Central Authentication System. But nothing happens. Either there isn't any security issue behind the login page ( :P ), or I couldn't login to the page (100% possibility :D ). For extra info:
These are login fields. ;)
username=
&password=
<=_c0C1F5872-F217-B20F-6D86-AA3AA1C1262E_kC7BEB4F7-5216-53EB-2F9A-7FDDFE01D145
&_eventId=submit
&submit=Login
Is there anyone who used Nessus and know how to solve this problem? And is there anyone who knows how to import Cookies to Nessus?
Thanks in advance. ;)
I had similar problems; can't speak for you, but sounds like you have about as much website knowledge as I do (which ain't much!) - no offense intended. In my case I'm not sure I'm understanding the most most basic structural elements of the website, such as what URL to point the scan at, and then concatenating that correctly with the login pages in the policy. I'm far better at the network and infrastructure penetration testing :D
I did a search in a search engine for "Nessus HTTP cookie import", and found that Tenable discussed this on their podcast, episode 14:
http://blog.tenablesecurity.com/2009/11/tenable-network-security-podcast---episode-14.html
If you look at the "Stories" note on the above web page, there's a hint to use the "Export Cookies" Firefox add-on. The add-on has some guidance, but essentially:
Install the add-on to your browser (I'm using the OWASP Mantra browser; I urge you to look at it)
Restart your browser
Login into the subject website and authenticate
From the Tools menu, go for "Export Cookies"
Save to file, and point your Nessus scan policy at that file
NOTE: I'm still trying this now, but thought I'd post the possibility anyway in case I forget - I will update this thread with a confirm or deny shortly.
Best of luck!
UPDATE: Well, it didn't work for me on first attempt. I'm confirming I don't have any conflicting or superseding settings in the policy, but if that doesn't work it's on to Tenable Support, I fear...
According to the documentation, besides importing cookies, the other way to do it (currently at 7.0) is:
Create new scan
Web Application Tests
Credentials:
which are filled out like these (taken from documentation):
Username: Login user’s name.
Password: Password of the user specified.
Login page: The absolute path to the login page of the application, e.g., /login.html
Login submission page: The action parameter for the form method. For example, the login form for: <form method="POST" name="auth_form" action="/login.php"> would be: /login.php
Login parameters: Specify the authentication parameters (e.g., login=%USER%&password=%PASS%). If the keywords %USER% and %PASS% are used, they will be substituted with values supplied on the Login configurations drop-down menu. This field can be used to provide
more than two parameters if required (e.g., a group name or some other piece of information is required for the authentication process).
Check authentication on page: The absolute path of a protected web page that requires authentication, to better assist Nessus in determining authentication status, e.g., /admin.html.
Regex to verify successful authentication: A regex pattern to look for on the login page. Simply receiving a 200 response code is not always sufficient to determine session state. Nessus can attempt to match a given string such as Authentication successful
However, looking at the reports, in my case, it couldn't authenticate for some reason