We are working with Opsview 6. I would like to insert a passive check result into the monitoring server remotely. The documentation is very vague about this, saying that it can be done via the API (no reference to this in the API docs), and that it is a part of the results forwarder. I don't see any open ports related to the results forwarder, so there must be something that needs to run to accept input somewhere, I'm just clueless what that might be. I'm willing to work with NSCA, NRD, or the API. Whatever works.
Related
I have a head-scratcher here. Over a year ago, I wrote a website feature/form where I could submit SQL Code that is not executed but stored in a table. This feature worked when I created it, as I was able to upload several scripts into the database. I have not needed to use this feature for several months, and recent upgrades to my website had me re-checking features. The feature stopped working ... and after some research, it was determined that our company firewall was now blocking the form from submitting due to a detection of "SQL Injection".
They swear that no changes were made to the firewall, however, this seems unlikely since this feature previously functioned. Regardless ... the confusion I have is that I know many websites, like this one, that allow people to post "code" using a web form interface without being flagged as SQL Injection. I am sure websites (like this one) have firewalls protecting them as well.
Is there something that needs to be done when transmitting code on a page submit/postback to clear a firewall's SQL Injection checks?
For clarification ...
There is a form, with a LargeTextArea control, where a SQL Script is entered. This SQL code is transmitted via postback to the server, and server-side code handles the saving of the script into a table. Very similar to what this website (StackOverflow) does I would assume. We can post code here, without it being intercepted and blocked by a firewall. The code we post here in our messages is eventually stored in a database on the server. That is the same behavior that I am performing.
Because of the firewall intervening between the client browser and the web server, the postback is never completed. Therefore, the server never receives the postback data to perform any processing. The client browser simply receives a "connection-reset" error.
I always thought of SQL Injection as something that should be handled server-side ... the responsibility of the programmer to ensure it is not abused. Having a firewall interfere prior to arriving at the server and having code execute to even check for SQL Injections ... feels wrong to me. Even if you have code that prevents SQL Injection, it would not matter if the firewall is intercepting and intervening prior to any server-side logic. Am I wrong?
Your firewall rules for SQL injection are blocking parameters that "look like" SQL injection - and that can lead to false positives for code that is not executed.
The correct way to get around this is to modify the firewall rule. See this answer for a way to that in ModSecurity.
Since this doesn't seem to be an option for you, you might consider bypassing the rule with obfuscation. For example - encrypting with a simple fixed key before putting it in the database (and decrypting on display) would hide this code from the firewall. And also provide some guardrails against it being executed in the future.
With bypassing security checks you are taking on a great responsibility. You should be very careful to ensure (and warn in comments) that this code is never executed. This includes executing it to check that it is correct SQL - which could also be abused for SQL injection.
After the security audit of Asp.Net Application I have received a error report and one error is as Source Code Disclosed.
How Should I resolve this issue by preventing any person to view code?
This is javascript code, which is really common to be exposed/disclosed (*) simply because it is intended to be downloaded to the browser where it then runs. To label this a risk might seem abundant, although there could be some risk depending on what it is that you put in it.
The question is mainly: could this code be exploited, or could it be altered into something that is dangerous?
The answer is to not put secrets in it, and also to never rely on client-side-only logic and validation. Always have a server side equivalent that enforces whatever rules need to be enforced, and use SSL/https so the connection is secure, and then you should be good.
(*) just hit F12, go to tab Sources or Debugger, and you'll see it here as well
I'm wondering if anyone else has had this issue with Azure Front Door and the Azure Web Application Firewall and has a solution.
The WAF is blocking simple GET requests to our ASP.NET web application. The rule that is being triggered is DefaultRuleSet-1.0-SQLI-942440 SQL Comment Sequence Detected.
The only place that I can find an sql comment sequence is in the .AspNet.ApplicationCookie as per this truncated example: RZI5CL3Uk8cJjmX3B8S-q0ou--OO--bctU5sx8FhazvyvfAH7wH. If I remove the 2 dashes '--' in the cookie value, the request successfully gets through the firewall. As soon as I add them back the request gets blocked by the same firewall rule.
It seems that I have 2 options. Disable the rule (or change it from Block to Log) which I don't want to do, or change the .AspNet.ApplicationCookie value to ensure that it does not contain any text that would trigger a firewall rule. The cookie is generated by the Microsoft.Owin.Security.Cookies library and I'm not sure if I can change how it is generated.
I ran into same problem as well.
If you have a look to the cookie value: RZI5CL3Uk8cJjmX3B8S-q0ou--OO--bctU5sx8FhazvyvfAH7wH there are two -- which is the potentially dangerous SQL command that can comment out your SQL command that you're going to query. An attacker may run their command instead of your command - after commenting out your query.
But, obviously, this cookie won't run any query on the SQL side and we are sure about that. So we can create rule exclusions that won't run specific conditions.
Go to your WAF > Click Managed Rules on the left blade > Click manage exclusions on the top > and click add
In your case, adding this rule would be fine:
Match variable: Request cookie name
Operator: Starts With
Selector: .AspNet.ApplicationCookie
However, I use Asp.Net Core 3.1 and I use Asp.Net Core Identity. I encountered other issues as well, such as __RequestVerificationToken.
Here is my full list of exclusions. I hope it helps.
PS I think there is a glitch at the moment. If you have an IP restriction on your environment, such as UAT, because of these exclusions Web Application Firewall is by-passing the IP restriction and your UAT site becomes open to the public even if you have still custom IP restriction rule on your WAF.
I ran into something similar and blogged about it here: Front Door incomplete first request.
To test this I created a web application and put it behind the Front Door service. In that test application I iterate over all the properties of the HttpContext.HttpRequest and print them out. As far as I can see right now, there are two properties that have differences between a direct request and a request through Front Door. Both the AcceptTypes and the UserLanguages property are empty for Front Door requests, while they are absolutely filled in when directly accessing the test application.
I’m not quite sure what the reason is for the first Front Door request to be different from a direct request. Is it a bug? Is it intentional and if so, why? Or is it because Front Door is developed using a framework that doesn’t support these properties, having them be empty when being forwarded?
Unfortunately I didn't find a solution to the issue, but to answer the question if anyone else is experiencing this: I did experience something similar.
Seems that the cookie got corrupted , as I was comparing the fields that existed before vs a healthy cookie, my guess is maybe somewhere in the content of the field it is being interpreted as a truncate sql statement and probably triggering the rule. Still to determine if this is true and/or what cause it.
I ran into this issue but the token was being passed through via the request query rather than via a cookie. In case it might help someone, for the specified host I had to allow via a custom rule doing a regex match on the RequestUri, using the following regex (taken from the original managed rule):
:\/\\\\*!?|\\\\*\/|[';]--|--[\\\\s\\\\r\\\\n\\\\v\\\\f]|--[^-]*?-|[^\\u0026-]#.*?[\\\\s\\\\r\\\\n\\\\v\\\\f]|;?\\\\x00
I have a spring-mvc web application which is "Active scanned" by ZAP tool. It has two High medium alert for SQL Injection which I believe is a false positive.
The original URL is /msg/showList? which returns 200OK and json list of message. ZAP while running scan, adds a parameter /deliverymsg/showList?query=query+AND+1%3D1+--+ which also returns 200 OK and json list of message. There is no change in response, the list is same. The application doesn't read the param "query" added by ZAP, so there is no actual SQL Injection here.
But ZAP alerts this as HIGH Medium.
The original URL is /filterlist?fromDate=&toDate=&_csrf=1534403682524 that returns 200Ok and list , ZAP is scanning and adds the condition for SQL injection /filterlist?fromDate=&toDate=&_csrf=1534403682524+AND+1%3D1+--+
This parameter is csrf token added by spring-boot implicitly, again not actually read by application directly. But ZAP alerts this as High Medium again.
I want to understand how ZAP is working here, and how to fix this false positive so ZAP doesn't alert. I have had cases in past, where I changed the application code to pass the test. But unable to think a clear solution for this.
Am thinking of adding HandlerInterceptor and check request param for any "AND" word and return HTTP400, I do not want to do it, coz it will be just to fool ZAP in not alerting HIGH.
I understand I can also give evidence of false positive and release this without fixing, but I cannot do that due to internal policies.
Am running ZAP in whatever default configuration it comes with.
Update:
I added HandlerInterceptor and rejected request having AND or query and so far re-running the ZAP for only the reported URL's didnt produce any alert. I wonder why is that? Because the URL's created by ZAP to attack has many more sql keywords like UNION ALL etc. I have only rejected request for two keywords.How could that solve the problem?
Why does ZAP appends it's own parameter query which application will never read, I dont understand the logic behind attacking with query.
It is possible that the findings are false positives. As you can imagine accounting for slight variances in app behavior across billions of potential web implementations is not exactly straight forward. Based on the details provided here it's hard to say. Usually for the SQLi alerts there is additional info in the "Other Info" section of the alert that may provide further clues as to ZAP's test and the observed "weirdness".
You can mark Alerts as False Positive in the UI (https://github.com/zaproxy/zap-core-help/wiki/HelpUiDialogsAddalert#confidence) or via the Web API. You can also install the "Context Alert Filters" addon and create rules in your context to set these as False Positive in the future. (Assuming you export/import your context.) [Further details on Context Alert Filters here > https://github.com/zaproxy/zap-extensions/wiki/HelpAddonsAlertFiltersAlertFilter]
ZAP's code is open source and publicly available so you can always look at the SQLi scanner (https://github.com/zaproxy/zap-extensions/blob/master/src/org/zaproxy/zap/extension/ascanrules/TestSQLInjection.java) and if you see an issue submit a PR with a fix, or open a new issue for the team: https://github.com/zaproxy/zaproxy/issues
I added HandlerInterceptor and rejected request having AND or query and so far re-running the ZAP for only the reported URL's didnt produce any alert. I wonder why is that? Because the URL's created by ZAP to attack has many more sql keywords like UNION ALL etc. I have only rejected request for two keywords.How could that solve the problem?
Well the alerts you received didn't have anything to do with the UNION injections did they? So simply preventing the issue that was being alerted upon (by filtering AND or query) you've hidden the behavior from ZAPs analysis. Further, the detection mechanism for boolean based SQLi and union based SQLi is different.
When you run an active scan that includes the Input Vector "URL Query String & Data Driven Nodes" then any request without a parameter will also be tried with the query parameter as that may sometimes uncover unknown handling (or mis-handling) within the web app, as well as some DOM XSS, etc. that may otherwise go undetected.
An interface has as a requirement that we do not include an expect-100. (The documentation is assuming I will be using c# or php code to talk and has the code to not send the expect-100)
I quickly googled around a bit and found many topics on how to disable this when not using BizTalk and found multiple posts that would make me believe that BizTalk sends an expect-100 by default as well. (BizTalk Data Services: Extended to bring management functions through IUpdatable and Adding Custom HTTP Headers to messages send via HTTP Adapter.). I have had trouble in finding someone trying to disable it.
Since I have found the C# code to disable it, would a solution be to create a custom pipeline component that disables this?
This is not something I would worry about. I don't recall ever seeing Expect: 100- continue in any trace to or from BizTalk using WCF.
I will say that it is very strange that they would have a dependency on not seeing this. Either way, if WCF is sending it, you should be able to remove it with a Behavior.
You'll have to set this all up to even see if it's a problem. Here's where I say just try it and see what happens.