PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → [WB] - Dynamic webdev site and session Hijacking
[WB] - Dynamic webdev site and session Hijacking
Débuté par Paulo Oliveira, 11 mai 2017 15:12 - 10 réponses
Posté le 11 mai 2017 - 15:12
After one scan of one webdev application we encounter the following problem:
If we copy the URL of one dynamic page send it by emails to another PC and use it the other user can see the data.

Anyone manage to solve this issue in the dynamic webdev sites?

Result of the scan:
Sensitive information within URLs may be logged in various locations, including the user's browser,
the web server, and any forward or reverse proxy or caching servers between the two endpoints.
URLs may also be displayed on-screen, bookmarked or emailed between users. This can also allow for
the disclosure of the session token to a third party via the Referrer header when any off-site links are
followed.
Placing session tokens into the URL increases the risk that they will be captured by an attacker. A
compromise would allow an attacker unauthenticated access to a valid user's session, placing the
application user's personal information at risk as well as increasing the likelihood of loss of integrity
and confidentiality within the application.
Session tokens hardcoded into the HTML for access to other locations can enable an attacker to
impersonate the application regardless of the user and gain access to application functionality or
information that usually requires a license.
Posté le 11 mai 2017 - 15:33
Hi Paolo,

If I copy and paste an url, I always get "The session does not exist anymore".

Kind regards,
Piet
Posté le 11 mai 2017 - 15:56
Hi Piet,

Using the same app installed in the same server and tested with several clients sometimes i get the same result as yours but in some other cases i can seee the data of the other user session.

In fact this problem was discovered by HP when we asked for one vulnerability scan to our server and app.
Posté le 11 mai 2017 - 16:24
Hi Paulo,

there are several solutions to solve this problem... They all bog down to identifying the COMPUTER using the session.

1. During login, you can setup a cookie on the user's computer. This cookie will not be there on another computer and your check of (by example) session ID will fail and protect your data

2. You can get the user IP address on the server side and store it in the DB.
Then at the beginning of each page init code (in the page model, of course), you can check that the IP is the same (that will not work well with people like me doing load balancing on several ADSL lines, but my case is quite rare) and of course anybody behind the same internet access point will have the same IP address.
If necessary, yoy can even maintain a white list of authorized IP addresses

3. You can use browser fingerprinting to identify the browser/user/system and compare it as above.

...

Best regards
Posté le 11 mai 2017 - 16:27
Hi Paulo,

To give you an idea, you can read all about security and anti-forgery (session hijacking) and how it is implemented by default in asp.net core here.

You'll see that it works with an anti-forgery token out of the box as it is part of the framework.
I haven't seen anything similar in WB... But I guess that by trying to make web development too graphical and "easy" (which they actually don't get to because you have absolutely no control on the internals and the output and then it becomes extremely difficult if you're blocked) PCSoft is probably missing features in this area...

Web security in itself is a huge domain... More on all Web Security features as they are implemented in asp.net can be found here. It'll give you an idea of the vastness of the subject

Cheers,

Peter
Posté le 11 mai 2017 - 16:53
Fabrice,

I'm using the method you describe in point 1 but the app scan still reports the error.
I can't use method 2 because all of my client are behind one router with NAT and i always get the same IP.

How can i get the browser fingerprinting?
Can it be done using the SysEnvironment function or it must be done in another way?

Peter,
That was my problem i was trying to find out if WebDev has any solution for this kind of problems as it's addressed by default in asp.net
Posté le 11 mai 2017 - 19:29
One possible solution I'm thinking about would be:
1. Store the value of CurrentPage in one global variable in the first page of the app
2. In all the other pages check if PreviousPage = content of the global variable
3. If true, store the current page in the global variable
4. if false end the app

I tested this with two simple pages and it looks promising but maybe I'm forgetting something or I'm making a mistake in the tests.

All comments and critics are welcome
Posté le 12 mai 2017 - 13:14
I have a login page, when closing this page I use the contextclose resource, in my case this problem does not occur that you are having
Posté le 15 mai 2017 - 11:06
Hi Paolo,

You could also use NetMachineName() to identify the workstation.

Kind regards,
Piet
Posté le 15 mai 2017 - 12:36
hi Paulo,

I'm confused also. I thought a dynamic page with automatic session management option (AWP unchecked) placed the session id in the url, hence if the url is coped between browsers / computers while session is active on server, it would still work and data associated with session would follow.

I thought the use of AWP and ConfigureAWPContext, when set to transmit session context through cookie instead of url, deals with this properly. This scenario URLs can be copied, but since session context is transmitted through cookie, the session id isn't copied with the url.. Let me know if I missed something..
Posté le 15 mai 2017 - 14:05
Hi Mr. Black,

The exact scenario (as stated above) is excellently described here.
Quote
Microsoft asp.net

Cross-site request forgery (also known as XSRF or CSRF, pronounced see-surf) is an attack against web-hosted applications whereby a malicious web site can influence the interaction between a client browser and a web site that trusts that browser. These attacks are made possible because web browsers send some types of authentication tokens automatically with every request to a web site. This form of exploit is also known as a one-click attack or as session riding, because the attack takes advantage of the user's previously authenticated session.

Example:

...

In short and what it comes down to in this case is that the WB cookies or tokens can be hijacked and used from another browser session.
A security flaw that can be dealt with by default in the asp framework in several ways.

Cheers,

Peter Holemans