We're having trouble passing a token between our system (IIS) and an affiliate mall site using IIS Web Services.
I need to see the data that's being passed to debug the issue, but the traffic is encrypted. I understand the scenario of using either Wireshark or Fiddler2 if I had the private key...I doubt the partner will supply us with theirs...
So, is there a logging method on IIS7 or debug mode I can use to decrypt the traffic, or is there another method without the need of decryption. My feeling is we'll have to see if the partner has a debug mode they can flag so we can temporarily see the data in the packets.
Related
I'm following the guide here to setup Application Insight telemetry on a frontend web form. I wish to use the snippet-based setup. I notice, however, that it requires me to embed the connection url in the html page. Is that a security issue?
There would be nothing to stop a malicious user from using browser dev tools to grab that url and then send any API calls to that url. Should I be concerned about this? If so, what is the recommended approach for securing this connection url.
... what is the recommended approach for securing this connection url.
There is none. For now you have to accept it is visible somehow. See also this open issue regarding the topic
Should I be concerned about this?
Not so much. The instrumentation key cannot be used to read any telemetry. However, it could be used to send bogus telemetry to your application insigths resource. This could lead to higher costs depending on the amount of data ingested and it could clutter your logs, possible masking possibly relevant telemetry.
Unless the application is hosted on a vnet integrated resource you cannot restrict access to application insights resource. If it is, then you can set application insights to deny queries or ingestion from external sources in the network isolation setting.
https://learn.microsoft.com/en-us/azure/azure-monitor/logs/private-link-security
So even if someone gets the url they cannot access.
We use Google App Engine and the provided load balancer to do SSL offloading for our API requests which are served by NodeJs. A third part is using Fortify to determine that even though it is https to the outside, because it is http inside the containers, it is considered a vulnerability.
Everything we read suggests setting the environment up this way.
Is this really a vulnerability and if so, how would we best mitigate against this without having to add paid certificates into our Node app.
Thanks in advance
Is this really a vulnerability and if so, how would we best mitigate
against this without having to add paid certificates into our Node
app.
Yes, the proxy of HTTPS to HTTP is a vulnerability as data is decrypted in transit. However, the connection between the frontend and your application is very hard to exploit outside the Google data center. I am not aware of a method to exploit this item.
In the cloud and on-premises data centers, proxying of HTTPS to HTTP is very popular. This offloads the CPU intensive process of encryption and decryption.
In security, there are almost always exceptions that need to be documented. This is one of them.
For the second part of your question, the proxy is HTTPS -> HTTP. This means that you cannot add your own SSL certificate to your backend code. If you did, you would have connection protocol errors.
If you must mitigate this problem, then you must select a different service and deploy your code with frontends/backends (web servers/proxies/load balancers) you configure and control.
I'm building a service that allows to enter activation keys in a desktop application, which will then call a web service to check the key and return a license. This call does not require authorization.
The web application is running as Azure "App Service". I'm afraid someone will be trying to "guess" activation keys and slow down my service. (I'm not afraid they will be able to correctly guess, they are long enough).
Do Azure WebApps have some kind of automatic rate-limiting or DOS-protection, or do I need to configure/code this myself?
If I have to do it myself, can you point me into the right direction?
As far as I know, we could use Dynamic IP Restrictions in web app.
The Dynamic IP Restrictions Extension for IIS provides IT Professionals and Hosters a configurable module that helps mitigate or block Denial of Service Attacks or cracking of passwords through Brute-force by temporarily blocking Internet Protocol (IP) addresses of HTTP clients who follow a pattern that could be conducive to one of such attacks. This module can be configured such that the analysis and blocking could be done at the Web Server or the Web Site level.
About how to config this feature. We could remote connect to the azure web app IIS and set it.
About how to remote connect web app IIS, you could refer to this article.
More details, you could also refer to this blog.
I have a mobile application that communicates with a REST based web-service. The web-service lives behind the firewall and talks to other systems. Currently this web-service requires a firewall port to be opened and a SSL cert generated for each installation. Mobile apps sends login credentials so web-services can login to custom back-end systems.
Recently a customer approached us asking how could we deploy this to 50 offices. As we don't want to say modify every firewall in every office, we're looking for options.. This is a list of possible solutions and my thoughts on each one:
Open firewall port and expose https webservice - This is our current
solution but we dont want to have to contact 50 network admins and explain why we need to do this.
VPN - Too heavy weight, complex and expensive, we only need access
to one server. Does not solve problem as firewall needs to be
modified.
Microsoft Azure Hybrid Connection Manager - This provides a managed
service where the Azure cloud will expose an end point. Azure will
also expect connections from a easy to install application that
lives behind the firewall. When a REST call is made to the cloud
end-point, the request is forward down socket that was initiated by
the software behind the firewall. This does what we want but as its
a Microsoft Solution there might impose other requirements that our
customers might not want. Currently the simple Hybrid Connection Manager is free. But for how long?
Jscape MFT Gateway - Similar to Azure but you can host their server anywhere. Not that expensive but is not opensource.
Netty - A async java library/toolkit where this type of application could easily be build. Client and server apps would need to be build and deployed. Dont know what we dont know about Netty.
MDM, AirWatch, BlackBerry BES - A MDM based solution would work expect that MDM's are centrally managed and are not often in every office where the backend services are located. Airwatch has an AppTunnle but im not sure about the specifics.
At this point the Microsoft and Jscape systems are possible solutions.
But most likely these solutions will require us to modify the mobile software to work around issues such as:
How does the user know which server to login to? A locator service
needs to be built such that, an email address is used to lookup their
office, or they need to select their office location from a list.
While the connection is SSL many company might want some additional protection since network login information will be send down the pipe.
How is load balancing and fail-over managed?
So, at this point i'm looking for more options. The best option would be a commercial product that offers some level of customization. Second, would like a well used open-source product that could be installed in Aws and customized.
Thanks
The best approach we found was to use the PUTTY API and setup a reverse proxy.
I have a requirement, that the SharePoint portal of our company should be made accessible from internet, as in
once URL is entered in the browser, it should ask for credentials- once entered, should display the homepage of the portal.
Provided it should be accessible from the current intranet also.
It is in windows authentication mode currently.
Disclaimer: This question would be more appropriate in a forum like SuperUser or Sharepoint StackExchange. I am not a system administrator so my answer will lack detail and probably wont be optimal.
The only thing you need to provide is access from an external interface to your network. So something that routes requests from outside of your network to your sharepoint instance.
This is usually achieved through a reverse proxy and proper configuration of DNS. You can setup a reverse proxy by different means, if your organisation uses the Microsoft Stack then I suggest setting up IIS as a reverse proxy to your Sharepoint Instance. There are multiple tutorials on how to do this on the web.
http://sahelp.sharepointforall.com/FAQ/bconfigure_IIS.html
You then need to add an entry to your organisation DNS hosting something like sharepoint.organisation.com that points to your external interface (public IP) where the reverse proxy is sitting.
You will then need to add an Alternate Access Mapping to your Sharepoint WebApplication so Sharepoint can route the requests that the proxy sends to the appropriate Webapplication.
http://blog.blksthl.com/2012/12/03/a-guide-to-alternate-access-mappings-basics-in-sharepoint-2013/
If you are using basic authentication make sure you enable SSL. this can be done in several ways but a possible and easy (but not the most secure) is to enable SSL just externally and then use a normal unencrypted channel on the inside of your network, this is probably the easiest setup but again not very secure as people inside the newtork can snoop comms between the proxy and the sharepoint instance.