I have a SPA application (angularjs front end/restfull WebAPI back end).
SPA is by design using client routing - i.e. typical "page" looks like
http://contosco.com#/page1
http://contosco.com#/page2
.. etc
I know that ZAP has "ajax spidering" mode in which it can get urls "from javascript". However the active scan is just making http requests - so I doubt the ZAP can be used in this scenario - or am I wrong ?
What sort of vulnerabilities are you looking for?
Your application will still have to make http requests, so ZAP will still be able to test those.
We also have a DOM XSS scanner https://github.com/zaproxy/zap-extensions/wiki/HelpAddonsDomxssDomxss which you can download from the ZAP Marketplace. This will launch a browser to detect DOM XSS vulnerabilities.
Also very happy to write more client side rules, just tell us what you are looking for...
Related
I am using OWASP ZAP to scan my web-application, developed using asp.net framework/C#.
I am being tasked by company to ensure NO error reported by OWASP ZAP.
The OWASP ZAP reported this log:
Issue: Cross Site Scripting (DOM Based)
URL:
http://[WEBSITE]/myapplication/script.aspx#jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e
I understand that the fragment (#hex) will not be sent to server for processing, it is more for browser to process.
So what do i suppose to do to ensure it never gets reported again in OWASP ZAP?
I've done following actions, but with no luck:
On the page, I embedded the javascript code, to remove the hashtag in the url. (Remove fragment in URL with JavaScript w/out causing page reload). It works, and I can see it being removed on the browser. But OWASP ZAP still reporting it as problem.
Similar to #1, i come out with javascript to detect whether #-fragment-url exists in URL. If exists, then redirect to "error" page. It is working, but ZAP again still report it as problem.
I guess since browser never send the # to the server for validation, i have no way to sanitize it. By the time ZAP/browser receives the response, ZAP will report it as issue.
So, what shall i do? I just want OWASP ZAP never report this issue anymore.
Any ideas?
I am working on an API in .NET core 2.
Everything works great when testing on https://localhost:44333, but when trying on http://localhost:44333 it does not work anymore. It just loads, and loads, and loads.... Nothing to see in the logs or anything like that.
The thing is, I need to get it working on HTTP because I want to try it on my phone in the app. So I use iisexpress-proxy to proxy it. This works when I can access the API on HTTP, but it doesn't work with HTTPS.
So therefor I need it to work with HTTP, but I have no idea why it does not work on HTTP. All my previous projects worked fine on HTTP and for some reason this one does not. I have looked in my startup if it might be forced or something like that, but I cannot find any...
You probably need more information than this, but I don't know what you need, so If you ask in the comments I will provide some more information/logs/code you name it.
The http version will be served on a different port. You'll need to look at your project properties to see which port it's being served on.
Just as some background:
There's effectively a client-side and server-side component to SSL. The http or https is the client-side component. That means the browser or other web client will either try to negotiate a secure socket or not, respectively. The server-side component is the port binding, which will either be a secure socket or not.
The forever-loading is because your client is trying to make a non-secure request, but the server's socket is attempting to negotiate SSL. It's like one person speaking Chinese and the other speaking Spanish. They're both communicating, but nothing gets accomplished.
Does Fiddler add anything to a request that I can use to detect, on the server, when I am using it as a proxy?
I currently add a header to every request using OnBeforeRequest to show Fiddler is being used as a proxy (but I keep forgetting to do it so I would like a more reliable option).
Someone is bound to ask why ... we are testing a web api and mvc application, and want to perform certain actions when we attach Fiddler. This is the simplest of several options, but it would be nice to not have to remember to add a detectable request header through OnBeforeRequest
I have an ASP MVC3 website with a rest API service.
When a user passes in an invalid API or they have been blacklisted i wish to ignore the response.
I know I could send back a 404 or pass back an 503 but if someone keeps polling me then I would ideally like to ignore the response causing a time-out their end. Thus delaying the hammering my server gets.
Is this possible within ASP.net MVC3? If so any help would be most appreciated.
Thank you
For what you want, you still need to parse the request, so it will always consume server resources, specially if you have an annoying user sending a query every 500ms...
In this situations you would block the IP / Header of the request for a period of, for example 10 minutes, but it would be a very good idea to block it on your load balancer and prevent that request that even reach your application, this is easily accomplish if you're using Amazon Services to run your Service, but all other cloud provider do support this as well, if by any means you are using a cloud hosting.
if you can only use your web application, and this is a solution that is not tested, you could add an ignored route to your routing mechanism like:
routes.IgnoreRoute("{*allignore}", new {allignore=#".*\.ignore(/.*)?"});
and upon check that the IP is banned, simple redirect using for example Response.Redirect() to your site, to a .ignore path... or, why not redirecting that request to google.com just for the fun of it?
I'm wondering if there is a way to ensure that an ASP.NET application can only be run using the HTTPS protocol
I'm fine with any code (defensive programming measure perhaps?) that can do the trick, or possibly some IIS/web server setting that can get the job done.
IIS will definitely allow you to require HTTPS. The instructions are here.
Edit: I had to go dig for it, but there's also Request.IsSecureConnection for defensive programming.
The only problem with enforcing the SSL on the IIS level is that the user receives an ugly 403.4 page error
"The page must be viewed over a secure channel"
To make the transition seamless, you could redirect the user to the secure site using the Request.IsSecureConnection if they do not generate the request over SSL.
There is a nice article that has some good information and a helper utility class on this subject over at leastprivilege.com