From 09252c5efcb558f7ca555fe7baa5644ef0263ac6 Mon Sep 17 00:00:00 2001 From: Ben Jones Date: Thu, 3 Oct 2024 21:56:05 +1000 Subject: [PATCH] improve cyber docs --- .studentResources/CSRF/README.md | 14 +++++ .../Cross_Frame_Scripting/README.md | 23 +++++++ .../index.html | 2 +- .../Cross_Frame_Scripting_Tester/README.md | 3 - .../images/favicon.png | Bin 15523 -> 0 bytes .studentResources/XXS_scripts/README.md | 52 +++++++++++++++- .../data_sanatising/data_handler.py | 39 ------------ .../defensive_data_handling/README.md | 25 ++++++++ .../defensive_data_handling/data_handler.py | 56 ++++++++++++++++++ .../main.py | 0 .studentResources/safe_API/README.md | 7 ++- 11 files changed, 174 insertions(+), 47 deletions(-) create mode 100644 .studentResources/CSRF/README.md create mode 100644 .studentResources/Cross_Frame_Scripting/README.md rename .studentResources/{Cross_Frame_Scripting_Tester => Cross_Frame_Scripting}/index.html (90%) delete mode 100644 .studentResources/Cross_Frame_Scripting_Tester/README.md delete mode 100644 .studentResources/Cross_Frame_Scripting_Tester/images/favicon.png delete mode 100644 .studentResources/data_sanatising/data_handler.py create mode 100644 .studentResources/defensive_data_handling/README.md create mode 100644 .studentResources/defensive_data_handling/data_handler.py rename .studentResources/{data_sanatising => defensive_data_handling}/main.py (100%) diff --git a/.studentResources/CSRF/README.md b/.studentResources/CSRF/README.md new file mode 100644 index 0000000..ac4f20f --- /dev/null +++ b/.studentResources/CSRF/README.md @@ -0,0 +1,14 @@ +# Cross-Site Request Forgery (CSRF) + +Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application. + +## How to secure against this attack + +- End user education. +- Https encryption. +- End user education. +- Implement a CORS Content Security Policy (CSP). +- Understand how the attack can be executed in the specific conext of the application and user then code review with specific senarios in mind. +- Implement three-factor authentication (3FA) for administrative opperations. +- Seperate production and development environments. +- Whitelist firewall policies diff --git a/.studentResources/Cross_Frame_Scripting/README.md b/.studentResources/Cross_Frame_Scripting/README.md new file mode 100644 index 0000000..1d769e6 --- /dev/null +++ b/.studentResources/Cross_Frame_Scripting/README.md @@ -0,0 +1,23 @@ +# Cross Frame Scripting + +Cross-Frame Scripting (XFS) is an attack that combines malicious JavaScript with an iframe that loads a legitimate page in an effort to steal data from an unsuspecting user. This attack is usually only successful when combined with social engineering. An example would consist of an attacker convincing the user to navigate to a web page the attacker controls. The attacker’s page then loads malicious JavaScript and an HTML iframe pointing to a legitimate site. Once the user enters credentials into the legitimate site within the iframe, the malicious JavaScript steals the keystrokes. + +[This example](index.html) demonstrates how easy it is to spoof a webpage, in this case the Unsecure PWA. + +This attack is particularly effective on mobile devices as the browser hides most of the URL and the the spoofing page only requires some HTML and some inline JS. Which is why XFS coupled with SMS scams are some of the most sucessful. + +> [!NOTE] +> Make sure the Unsecure PWA is being served at [http://127.0.0.1](http://127.0.0.1) before opening the demonstration page. +> `python main.py` + +As a more sophisticated attack the threat actors would: + +1. Serve both sites through a proxy circumventing any CORS CSP policy +2. Have a back to base script that intercepts and transmits input data (username, password, credit card, etc) without the user knowing. +3. Have a threat actor listening for inputs and interacting/handling the victim, which is how 2FA is often bypassed. + +How to secure against this attack + +1. End user education. +2. Monitor http logs for unusually repeative GET calls. +3. Implement Content Security Policy (CSP) preventing `` \ No newline at end of file +4. `` + +## How to secure against this attack + +1. Regular code reviews +2. Only known and secure 3rd party javascript libries should be externally linked. Preferably 3rd party libraries should be locally served after a code review. +3. Defensive data handling +4. Declare the language `` +5. Delare charset `` +6. Content Security Policy (CSP) Blocking `` and `