We use Application Insights on Frontend and we also use Azure Front Door with WAF(Web Application Firewall) policy.
I can see in WAF logs that a lot of requests are blocked by some WAF Managed Rules.
When I have inspected the WAF logs I found out that requests are blocked by value in cookies ai_session and ai_user (App insights cookies).
Rules that blocks requests:
(942210) Detects chained SQL injection attempts 1/2 - block request because of OR value in ai_session cookie like this:
D/6NkwBRWBcMc4OR7+EFPs|1647504934370|1647505171554
(942450) SQL Hex Encoding Identified - block because of Ox value in ai_user cookie like this:
mP4urlq9PZ9K0xc19D0SbK|2022-03-17T10:53:02.452Z
(932150) Remote Command Execution: Direct Unix Command Execution - block because of ai_session cookie with value: KkNDKlGfvxZWqiwU945/Cc|1647963061962|1647963061962
Is there a way how to force App Insights to generate "secure" cookies?
Why does Azure generate cookie values that on the other side cause blocking requests by Azure Firewall?
I know that I can allow those WAF Rules but is there any other solution?
We have started to encounter this error as well; disabling (or setting to allowed) the OWASP rules as you indicated will work.
I have opened a bug report on the project page that outlines this in more detail here: https://github.com/microsoft/ApplicationInsights-JS/issues/1974 the jist of it, as you identified is the WAF rule's Regex being overzealous.
The IDs that are eventually used by the cookies are generated by this section of code:https://github.com/microsoft/ApplicationInsights-JS/blob/0c76d710a0cd465f0b8b5e143250898122511874/shared/AppInsightsCore/src/JavaScriptSDK/RandomHelper.ts#L125-L145
If the developers chose, they have various way to solve the problem:
Test the generated cookies against the list of known regex and then regenerate on failure.
Remove some of the offending combinations to avoid the rules entirely.
We'll have to see how that plays out. If you cannot do this, in theory you could branch the project and then add such changes yourself but I would not recommend vendoring the SDK.
Related
I heard that Azure App Gateway's Web App Firewall is able to protect apps from SQL injection attacks. How does it actually achieve that?
Does it inspect all the incoming payload (both body and URL params)? If it does, I assume TLS termination has to be set up on the Application Gateway level, otherwise it wouldn't be able to read anything. Does it just look for some suspicious strings in the payload (like ";DROP TABLE....")? How does it know if the content in the payload is safe or not? I mean, I could be sending some payload to my web app that could look like SQL injection - how does the WAF know which request is an attack and which isn't?
Here is a list of reference material that OWASP used to create the rules for SQL injections. Essentially it is looking at the query to see if there is anything suspect in it (comments trying to obfuscate commands, backticks in the wrong place, trying to gain server/host information, etc). It is a long list, too long to describe here but the reference sites might be easier to understand than the raw rules.
References (from rule code):
SQL Injection Knowledgebase (via #LightOS)
http://websec.ca/kb/sql_injection
SQLi Filter Evasion Cheat Sheet -
http://websec.wordpress.com/2010/12/04/sqli-filter-evasion-cheat-sheet-mysql/
SQL Injection Cheat Sheet -
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/ (Link no longer valid) https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/ has background info
SQLMap's Tamper Scripts (for evasions)
https://svn.sqlmap.org/sqlmap/trunk/sqlmap/tamper/(Link no longer valid) https://medium.com/#drag0n/sqlmap-tamper-scripts-sql-injection-and-waf-bypass-c5a3f5764cb3 has details on the process.
We develop an React application with an Express NodeJS backend and this application is secured by an authentication using IBM App ID. Everything works fine on the authentication mechanism if the application is deployed on a Cloud Foundry Service with only 1 instance running.
For performance and high availability reason we need to scale up the number of instances. Unfortunately, as soon as we add an instance, we face problems with authentication. We loop over the authentication screen several times before the authentication succeeds and we can access the application.
For information, we use a Cloudant database to store the session.
Have you ever encountered this problem and how did you solve it?
Thank you for your feedback.
Technically what you are doing is the right thing.
I've encountered these problems before and first thing is usually local session handling - either the default memory store or some file based session store. You should have this covered, as you say you have sessions in Cloudant, but sometimes when you want to enable local developers running the app, you may need to have some switches to control if the shared store is used, but also if http or https is used.
Why http vs https is important, you probably have 'cookie: { secure: true }' which needs to be flip/flopped in that case. Next you might want to http trace the login attempt to see that you don't accidently use another host name than what you begun with. This could easily happen if your CALLBACK url for App ID changes it. These might still not be your reason, and if it is so - then setup that 2 instance environment, save the logs from app servers, http trace from browser and inspect created sessions from Cloudant. There should be only one session created, one url for application used, same session cookie saved in browser. If any of that does not add up - then you need to figure out why not.
I'm new to JMeter and trying to create test case.The application is using OAuth 2.0 azure active directory authentication,I followed one the post https://blog.pnop.co.jp/jmeter-webapps-azuread-auth_en/ and was able to do http request to app but in return I'm getting below error:
We can't sign you in
Your browser is currently set to block cookies. You need to allow cookies to use this service.
Cookies are small text files stored on your computer that tell us when you're signed in. To learn how to allow cookies, check the online help in your web browser.
I took care of CookieManager.save.cookies=true in user.properties but still cookies are giving me hard-time though I could see cookies populating in request header being sent
If someone have a crack of similar scenario then that would be great help
Thanks
Have you added HTTP Cookie Manager to your test plan?
If yes and you're still experiencing problems try:
Checking jmeter.log file for any suspicious entries
Choose a more "relaxed" implementation for the cookie manager, i.e. netscape
Add the next line to user.properties file:
CookieManager.check.cookies=false
JMeter restart will be required to pick up the change
More information: HTTP Cookie Manager Advanced Usage - A Guide
It's not a common question, but I wonder if any tricks or upcoming standards exist.
Belows are a flow and what I want to implement.
Web application loaded from server-side
Client-side script loads some secure contents (not from #1) that need to be protected from web application provider. It could be shown to a user visually.
Web application provider knows where are the secure contents (in Dom path) and possibly may try to catch it by putting a script
However the secure contents shouldn't be hijacked from servers (even from the same origin) or from external application (even from developer tools if possible)
EDIT:
For better understanding, it's for use case where web application doesn't hold user data in their DB but loads the data from somewhere else. In case, I need to protect the data from web application, which is uncommon in regular web application.
You should use a content security policy (CSP) which would enable the browser to deny injection attacks. These can be a little tricky to setup correctly so I would use Report URI to help you get it going. The trick is to use report only mode first until you have validated the settings then switch to enforce.
My web server got a hundred odd tries of accesses from Acunetix scanner within 1 minute!
How can I avoid these attacks, seeing that I have many different end users accessing the website per minute?
There are two main ways you can tackle this:
Setup tools such as Fail2Ban to automatically block IPs for users scanning your website.
Automatically block any requests using custom headers. In this case, see your web server's access log and see whether or not it is sending any custom headers similar to:
Acunetix-Product: WVS/X (Acunetix Web Vulnerability Scanner - NORMAL)
Acunetix-Scanning-agreement: Third Party Scanning PROHIBITED
Acunetix-User-agreement: http://www.acunetix.com/wvs/disc.htm
You can then block such patterns possibly using web server rules or a WAF (Web Application Firewall).