recently i have been working on shodan to gather information for my recon report. when i search my target domain it just says Note: No results found how is that possible? the website is up and running, but its behind CloudFlare. but i still wonder why does it not give me any results at all? what might be the reason?
It shows no results on censys either it just says Your query returned no results. why is it not showing me any results? does it mean the domain is virtual? but even if it is virtual how does it not show any information at all?
This means the target domain could be blocking Shodan and Censys. I would try looking for an SSL cert in the Censys Certificates Dataset with the target name on it.
Related
When I set the domain in the dashboard to xxxxxx.com, where xxxxx is my domain, I am still unable to make API calls from the domain given.
The error I get when I attempt to make an API call is:
"Unauthorized. The request is not from an authorized source."
There is no issue with the code itself as it was working before I had set a specific domain. I've also ensured that the domain typed into the dashboard is correct.
Any help would be appreciated, will provide more information, if needed.
It takes a bit of time for the changes to take effect. Please wait a little while, then try again. If it still doesn't work, please report back.
Alternatively please note that you also need to add any subdomains you may be using. For example, if you add "here.com", you would also have to add "www.here.com" and "developer.here.com" if you wanted API calls to be accepted from these subdomains.
I have some webservices which are called by some clients and that includes through mobile and web. I have no control on the clients code.
But, I need to identify who is calling my web services, via the IP address or something else.
Is there any way to identify that?
A better approach to tracking this sort of thing is to introduce the notion of an API key. That way you know exactly who is using your service and you can track their usage etc.
On every call to your service the user would have to provide their key as a means of authorisation (not authentication). This sort of approach can generally help avoid misuse of an API, however, it can't eradicate it completely. At least with this approach if you do find malicious user it's as simple as disabling that particular API key.
You should check your IIS Logs, these will list (if you have them turned on, default they are on) all the requests made to your server.
So search through the log for the URL of the service and check the logs around the time of requests you are having issues with and it will list the IP address.
Your logs can generally be found at: C:\inetpub\logs\LogFiles
If the folder is empty then you are out of luck currently, you will need to turn logging on in IIS and then you will be able to check them after a few hours and start seeing where requests are coming from.
E.g a sample from a log.
2012-10-29 04:49:44 129.35.250.132 GET /favicon.ico/sign-in returnUrl=%252ffavicon.ico 82 - 27.x.x.x Mozilla/5.0+(Windows+NT+6.1;+rv:16.0)+Gecko/20100101+Firefox/16.0 200 0 0 514
So the first highlighted item is the date and time, and the second highlighted item is the IP address (redacted as it's a real log.)
we recently migrated our application (IIS Server + DB Server) to AWS and also modified the network architecture a little bit. The entry point of the system is an Astaro Firewall (we use the AWS AMI) which also host the SSL certificate of the web server. Everything related to the firewall has been done by a vendor and we only have some read-only privileges.
We are getting 403 errors in a few situations but I will explain one, as they all may be related.
We got a form which query the database and return a report in HTML format (this report also have some checkbox to do updates). The first time the form is submitted, we always get the report back. If we wanna post the form again, updated with new data, it crash, returning error 403. We noted that it doesn't crash when the first results returned a very low number of rows (or none).
Looking at the details of the POSTs in Developer Tools, what seems to be the only difference between a working and 403 error reply is the size of the data posted. The second post is always bigger because it contains the data of the first report (as the page have also other option to checkbox the rows).
Also, looking at the IIS logs we don't see any traces of the POST that crash. Nothing at all.
This problem happen only in production. In dev environment it's all working flawlessly. The only difference is that the production have the firewall/ssl, while development is all open. This is why we think it may be related to SSL.
The vendor is not the most helpful, we are looking for help to pinpoint the issue and trying to take the situation in our hands.
Any input appreciated.
I'm using the Organization Service URI to upload documents to our SharePoint site from notes and attachments. I'm using the code found here and all is working apart from where i set the organizationURI. I get an error of "metadata contains a reference that cannot be resolved". I have tried retyping the link in and everything i can think of but i always get this error.
The strange thing is that this was working a couple of days ago just fine, but when i tried it the next morning it refused to work and now wont do anything at all. Before this error i have now i was getting an error saying that the URI scheme is not valid. I don't know what could have caused this to stop working but i've tried all i can think of and need some help.
Thanks
EDIT: The error message has changed to "A proxy type with the name account has been defined by another assembly". Still not sure what it means, but i'm hoping this might be easier to fix
I'm not sure if this is the actual fix for this problem but i tried this and it seemed to work. So either it is the answer or i was just lucky and something else changed too, but anyway...
What i did was to change the way that i was connecting to the organization service. Before i was using user credentials, organization URI and home realm uri together to get the OrganisationServiceProxy in the form of OrganizationServiceProxy orgService = new OrganizationServiceProxy(organizationUri, homeRealmUri, cred, null);.
Now i'm using a longer method of first setting the discovery service with user credentials. Then together with them i set the discovery service proxy, which is then authenticated. Then i simply use a RetrueveOrganizationRequest / Response to get the organization service which i can then use in place of the original.
Hope that makes sense to people but if anyone wants i can put some code up showing what i did.
I've requested an certificate (for SSL on IIS 7) with several subjectAltNames. I'd read that some people might not like to do this because of the public being able to see links between different sites. (This doesn't matter as the certificate is for internal use). But this suggests that I should be able to see the subjectAltNames when I view the certificate. I can't.
Should I be able to see them, and if so, where?
Yes -- but it depends on the certificate viewer that you are using.
Subject Alt Name is an extension to the certificate. It is still signed as part of the certificate signature, but it may not be viewable through all the things that see certificates. Where it specifically shows up is somewhat a factor of how you are looking at it. It is in the certificate extensions. Usually it's qualied as "Subject Alternative Name" or "SubjectAltName".
I just tested IE 7.0 on XP and it can show the Subject Alt Name. It shows up as one of the detail items.
Also, this site will:
http://www.redkestrel.co.uk/cgi/decodeCert.pl
As I've gotten Subject Alt Names out of it before. They show up in the extension section.
If it's not showing up there, the certificate may have been made without it, which means you will need to go back to the owner of the Certificate Authority and get the name recreated.
Another caveat - not all products will handle subject alt name. You'll need to test each one separately. I've heard of a number of cases of products not recognizing it or parsing it, and then throwing errors because the SubjectDN does not map to the subject alt name.