- Force an authorized user to send forged HTTP requests (utilize victim session data)
- victim must be logged in.
- These requests are considered as legitimate by vulnerable server-side application.
Accepting un-validated inputs, storing it in the database, presenting it to the user upon request and when logged in user accesses it the exploitation occurs.
- Unique token in hidden field (this causes value to be sent in the message body and not in the URL of request)
- Require user to re-authenticate before making a sensitive/important request.
- implement Captcha
- mobile SMS/OTP verification.
- Data extraction
- Remote code execution
- Scan internal systems
- Perform Denial of Service.
Your application is vulnerable if it uses SAML for identity processing and your XML Processor parses
- Untrusted XML Acceptance
- Untrusted XML Uploads
- Inserting untrusted data in XML
- sanitize input
- SOAP 1.2
- Patch and upgrade XML processor
DISABLE XML External Entity and DTD Processing in all XML Parsers in applications.
Data Security at Rest, In Transit and In Client Browser.
- Encryption – Key Rotation, Storage, Split Knowledge
- Data Masking
- No hard-coded credentials
- Disable Page caching (This comes in handy in case of permission changes)
- Re-verification of identity, object.
- no plain text data exchange
- no weak algorithms
- Discard sensitive data (from session/memory/cache etc.) ASAP.
- Preferably encrypt data even when it is in memory (performance overhead).
- Dictionary attack
- leaked credentials
- attacker gains access then causes identity theft, frauds, money, card, data frauds.
- Confirm users identity and session management
- implement multi-factor authentication.
- no default credentials ( or credential standards)
- Implement weak password checks
- length, complexity, history check,
- limit failed logins
- log every activity regardless of success or failure
- SERVER-SIDE SESSION IDENTIFIER.
Probably implement something using https://haveibeenpwned.com/