You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This problem can be mitigated with SSL encryption, either by purchasing an actual certificate or going through Lets Encrypt.
I had permission from @JMStudiosJoe to test some parts of the application and simulate a situation with a library volunteer and attacker on the same network. My 1st setup was a host machine and Kali Linux VM, with the "library volunteer" logging into the application on the host machine.
Scenario: Library volunteer logs in to a public network such as a guest network or cafe. An attacker on the same subnet sniffing for packets picks up the unencrypted traffic and uses it to gain admin access to the application
By spoofing the router gateway and targeting the host IP, an attacker is able to pick up network traffic as the user is logging in, particularly on POST /api/login packets containing the information to login, such as email, password, and cookie information if the library worker logs in successfully. The attacker in this scenario could either use the email-password combination to login, or use the cookie in browser extensions to hijack that user's session.
Solution: This problem can be mitigated through https encryption to hide the login information through plaintext. I was also unable to pick up the same traffic when having the targeted computer login while on a VPN, but an SSL encryption should suffice.
The text was updated successfully, but these errors were encountered:
@ErikaVasNormandy
We should definitely add SSL encryption, no code change is needed.
Let's get time together to discuss CodeForSanJose's strategy regarding certificate management.
This problem can be mitigated with SSL encryption, either by purchasing an actual certificate or going through Lets Encrypt.
I had permission from @JMStudiosJoe to test some parts of the application and simulate a situation with a library volunteer and attacker on the same network. My 1st setup was a host machine and Kali Linux VM, with the "library volunteer" logging into the application on the host machine.
Scenario: Library volunteer logs in to a public network such as a guest network or cafe. An attacker on the same subnet sniffing for packets picks up the unencrypted traffic and uses it to gain admin access to the application
By spoofing the router gateway and targeting the host IP, an attacker is able to pick up network traffic as the user is logging in, particularly on POST /api/login packets containing the information to login, such as email, password, and cookie information if the library worker logs in successfully. The attacker in this scenario could either use the email-password combination to login, or use the cookie in browser extensions to hijack that user's session.
Solution: This problem can be mitigated through https encryption to hide the login information through plaintext. I was also unable to pick up the same traffic when having the targeted computer login while on a VPN, but an SSL encryption should suffice.
The text was updated successfully, but these errors were encountered: