Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 2 Wochen
Letzter Beitrag:
vor 1 Tag, 12 Stunden
Beteiligte Autoren:
Paulo Oliveira, Piet van Zanten, Allard, Peter Holemans, Fabrice Harari, Mr Black

[WB] - Dynamic webdev site and session Hijacking

Startbeitrag von Paulo Oliveira am 11.05.2017 13: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
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.


Hi Paolo,

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

Kind regards,

von Piet van Zanten - am 11.05.2017 13:33
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.

von Paulo Oliveira - am 11.05.2017 13:56
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

von Fabrice Harari - am 11.05.2017 14:24
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



von Peter Holemans - am 11.05.2017 14:27

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?

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

von Paulo Oliveira - am 11.05.2017 14:53
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

von Paulo Oliveira - am 11.05.2017 17:29
Hi Paolo,

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

Kind regards,

von Piet van Zanten - am 15.05.2017 09:06
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..

von Mr Black - am 15.05.2017 10:36
Hi Mr. Black,

The exact scenario (as stated above) is excellently described here.
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.

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.


Peter Holemans

von Peter Holemans - am 15.05.2017 12:05

few thing one can do that will reduce the problem.

1 check ip adres of the browser that does the login page. Store this in a global var

2 In the ini of every page that follows. Check if the ip adres of the browser is qual to the ip adres stored in the global var. If not shutdown session.

This solves quite a bit. Hostile hackers are more often using a different IP adres I guess?

You can narrow this by checking the browser used. The verion of that browser used etc.

For me the ip adres is enough


von Allard - am 19.05.2017 12:27
Hi allard,

For us the IP isn't enought, several clients arrive with the same IP.

I cant' find a way to get client fingerprint (wich broswer, version, etc..)
can you help me pointing the way to get this information?


von Paulo Oliveira - am 19.05.2017 13:18
Hi Paolo,

What about NetMachineName()?
In the LANs I know the machine names are different so that combined with IP would make a unique identifier.

Kind regards,

von Piet van Zanten - am 19.05.2017 14:03
Hi piet,

I'm already using ip address and machine name but i would like to use as much data as i can to prevent this problem because none of this can guarantee the uniqueness of the client.

von Paulo Oliveira - am 19.05.2017 14:07
Hi Paulo,

The functions beginning with "browser" are your friend:



von Allard - am 20.05.2017 17:31
Thanks Allard,

That's what I was looking for.

von Paulo Oliveira - am 22.05.2017 08:24
Do not rely on these functions to ensure they do not copy / paste the URL.

If you check the remarks of this functions (BrowserVersion for instance) you will see that it doesn't detect if copy/paste the URL in another browser.

"For a dynamic site (non-AWP site), the returned value corresponds to the browser used when connecting to the site. If the Web user changes browser (via a copy-paste of URL into another browser for example), this change is not detected."

von Paulo Oliveira - am 22.05.2017 10:29
Hi Paulo,

Hmm tested this and with me it does get detected. If in browser code unload.
then relay this to server code and check if equal.

In every serverprocedure do the check as well. Then they maybe see one page but cannot do anything after that.


von Allard - am 22.05.2017 13:24

I didn't test it,

I only checked the functions in the help and found the remarks.

von Paulo Oliveira - am 22.05.2017 14:10
Hi Paulo,
I tested on my dev machine. So not representative. Get what you mean. Thanks


von Allard - am 23.05.2017 20:42
Hi Paolo,

In the end we are actually talking about the risk of insecure hardware or careless users.
These are the most frequent security risks.
If they leave their pc unattended, do you really think that this is your responsibility?

Kind regards,

von Piet van Zanten - am 24.05.2017 11:00
Hi Piet,
If you try to subject your app to a security scan this is one major problem.
i can't control all the hardware used to access my app, the app is publicly accessed.

In my inicial post you can see the result of the scan.

WebDev dynamic sites fails in the OWASP Top 10: A2, A5
Tokens should not be hardcoded within the application where it may be seen and
abused using an interception proxy.

von Paulo Oliveira - am 24.05.2017 11:15
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.