Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
WinDev Forum
Beiträge im Thema:
25
Erster Beitrag:
vor 5 Monaten, 1 Woche
Letzter Beitrag:
vor 4 Monaten, 1 Woche
Beteiligte Autoren:
Paulo Oliveira, Allard, Piet van Zanten, Peter Holemans, Andrew Strubhar, 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
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.

Antworten:

Hi Paolo,

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

Kind regards,
Piet

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

Cheers,

Peter

von Peter Holemans - am 11.05.2017 14:27
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

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,
Piet

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.
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

von Peter Holemans - am 15.05.2017 12:05
Hi

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


regards
Allard

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?

Thanks

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,
Piet

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:

BrowserName()
BrowserOS()
BrowserPlatform()
BrowserType()
BrowserVersion(BrowserFullVersion)

regards
Allard

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
Allard,
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.
regards

Allard

von Allard - am 22.05.2017 13:24
Allard,

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

Allard

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,
Piet

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
Hi Paulo

Quote
pcsoft site
Accepting (or not) the return address The address returned by BrowserIPAddress may not correspond to the address of the Web user (if a non-transparent proxy or a Load Balancer is used for example). In this case, BrowserIPAddress returns the IP address of the proxy or Load Balancer.
If the return address is accepted, BrowserIPAddress tries to read the initial address specified in the HTTP headers (most of the proxies provide the initial address in the HTTP headers). However, this address must be used with great care because it is not reliable and it can be entirely wrong.
Notes:
If the initial address is not found or if it is invalid (address too long for example), the "standard" address is sent.
In test mode, Browser IP Address returns the address of the development computer.

Pre-launched sessions
If your project is using pre-launched sessions, this function must not be used in the "Initializing the project" process. This function must be used in the "Initializing the project after connection to the site" process.


This does not matter. It will do just fine. The user logs in and just after checking the credentials a the ip address is recorded .

Then user after login is presented with first page of application. Before showing a check is done if the stored ip address is equal to the newly check. In initiation of the page a new check on the ip is done.

They have to be equal. If not a page is displayed with error or login page is displayed.

So it does not matter if this is not the right ip address it is the address that is gotten via the check ( can be the address from the proxy as stated in the pc soft text ) the checks are the same . And different if someone has an other ip address.

It cannot be used to exclude access but it can be used for making sure it is the same user with a margin that someone form the same proxy passes the check.

For that the extra functions can be used


regards

Allard

von Allard - am 28.05.2017 21:43
The issue is that WebDev stores the session token in the URL. If you copy/paste it, then the server assumes the session is the same.

I don't recommend enforcing IP addresses because a dynamic IP can change and kick the user out. It's also not very secure. Additionally, users share the same IP address as you noted.

The solution is to use a cookie to store the session token. This is what Facebook and other major websites do.

I apologize but I don't know how to set this in WebDev. I only used that language for a few months.

If you take a look at the PHP documentation (I know we're talking about different languages), you can see it has two modes for session storage (cookies; URL parameter). This is the core concept and the heart of the problem.

http://php.net/manual/en/session.idpassing.php

von Andrew Strubhar - am 06.06.2017 14:45
Hi Andrew,

For the moment i'm using one cookie to store one session variable generated with GetGUID
at the project init code and in every page i'm cheking if my in memory value is the same as the value in the cookie and if the value isn't the same i close the session.

This is the best i can do for now.

von Paulo Oliveira - am 06.06.2017 15:06
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.