With Java 7u55, an applet will display a warning message (even if signed with a trusted cert) if a webpage tries to interact with it via JavaScript and that page isn't listed in the manifest’s Caller-Allowable-Codebase attribute.
If Caller-Allowable-Codebase : IP Address of server is given then security prompts are not seen.
However,our application is an intranet site and hosted in IIS.
Client system access the Website at http:://<ServerName>/<WebSite VirtualPathName>
The server name/IP Address is not the one which is fixed. The application can be installed in any Web Server.
Is there any way around to stop the warning prompt?
Short answer is no. The only thing is that your are able to put several domains/ips in the attribute:
host.example.com 127.0.0.1 192.168.1.100
If its an internal network you may try to use 192.168.0.* or 192.168.0.1/24
In the release notes of 7u55 you can read the following:
Using "" in Caller-Allowable-Codebase Attribute If a stand-alone
asterisk () is specified as the value for the
Caller-Allowable-Codebase attribute, then calls from JavaScript code
to RIA will show a security warning, and users have the choice to
allow the call or block the call.
Additionally the JAR File Manifest Attributes documentation states:
The Caller-Allowable-Codebase attribute is used to identify the
domains from which JavaScript code can make calls to your RIA without
security prompts. Set this attribute to the domain that hosts the
JavaScript code. If a call is made from JavaScript code that is not
located in a domain specified by the Caller-Allowable-Codebase
attribute, the call is blocked.
If the Caller-Allowable-Codebase attribute is not present, calls from
JavaScript code to your RIA show a security warning, and users have
the choice to allow the call or block the call. For unsigned RIAs,
JavaScript code that requires access to the RIA must be in the same
location as the main JAR file for your RIA, otherwise, the user is
prompted to allow access.
See Codebase Attribute for a description of the values that are
allowed. If a stand-alone asterisk (*) is specified as the value for
the Caller-Allowable-Codebase attribute, then calls from JavaScript
code to your RIA show a security warning, and users have the choice to
allow the call or block the call. An option to remember the choice is
also provided, and if selected, the warning is no longer shown when
the RIA is launched.
Update:
I know that it is frustrating and on a personal note I think that oracle will destroy the usage of applets (or whats left of it) due to their latest security decisions. As you may saw is that the restriction only apply if you
omit the Caller-Allowable-Codebase attribute
or if you use a stand-alone asterisk (*)
What you can do is:
"specify more than one domain, separate the domains by a space"
I haven't tried it however I would put all internal ip adress ranges in there:
Caller-Allowable-Codebase: 10.* 192.168.* 172.* 169.*
If that works you may try to add all IP address ranges ;-)
Caller-Allowable-Codebase: 1.* 2.* 3.* 4.* 5.* .... 255.*
If the subnetting syntax works you may also try:
0.0.0.0/0 (whole IP 4 address space) or something like that
Related
I have a static web app to which I have mapped the domains [domain].se and www.[domain].se. The domain is managed in Azure.
The problem I'm facing is redirecting all calls to [domain].se to www.[domain].se
Since I couldn't come up with any solution to redirecting http traffic from [domain].se to www.[domain].se using a static web app (other than setting up an additional standard web app on [domain].se that manages redirects), I enabled the "Enterprise-grade edge" feature (which by the way is a very silly name) to be able to use FrontDoor.
When attempting to add the domain to the frontdoor resource, there is an error message telling me that it's already mapped to something (which is correct - the site that I want frontdoor to manage).
When trying to remap [domain].se (and www.[domain].se) to the front door endpoint (select Azure resource in the DNS zone manager), the frontdoor resource is not available.
The issue could probably be resolved by simply removing the current records from the name server and then add a cname record to point it to the frontdoor endpoint.
Two reasons not to do that:
1: It would cause downtime.
2: It feels like a hack. Stuff genereally work better when they are used the way they were expected to when developed. I want the platform to recognize what things are connected in order to avoid future issues.
I have a powershell script (but I think these considerations could be extended to any script that requires a runtime to interpret and execute it) that does what I also need to expose to a web application front end as a REST API to be called and I've been asked to call directly the script itself from the web method but although technically feasible, having a web api method that starts a shell/process to execute the script and redirecting stdin/stdout/stderr looks like a very bad practice to me. Is there any specific security risk in doing something like this?
Reading this question brings to mind how many of the OWASP Top Ten Security Vulnerabilities it would expose your site to.
Injection Flaws - This is definitely a high risk. There are ways to remediate it, of course. Parameterizing all input with strongly-typed dates and numbers instead of strings is one method that can be used, but it may not fit with your business case. You should never allow user-provided code to be executed, but if you are accepting strings as input and running a script against that input, it becomes very difficult to prevent arbitrary code execution.
Broken Authentication - possibly vulnerable. If you force a user to authenticate before reaching your script (you probably should), there is a chance that the user reuses their credentials elsewhere and exposes those credentials to a brute force attack. Do you lock out accounts after too many tries? Do you have two-factor authentication? Do you allow weak passwords? These are all considerations when you introduce a new authentication mechanism.
Sensitive data exposure - likely vulnerable, depending on your script. Does the script allow reading files and returning their contents? If not now, will it do so in the future? Even if it's never designed to do so, combined with other exploits the script might be able to read a file from a path that's outside the web directory. It's very difficult to prevent directory traversal exploits that would allow a malicious user access to your server, or even the entire network. Compiled code and the web server prevent this in many cases.
XML External Entities - possibly vulnerable, depending on your requirements. If you allow user-provided XML, the bad guy can inject other files and create havoc. This is easier to trap when you're using standard web tools.
Broken Access Control - definitely vulnerable. A Web API application can enforce user controls, and set permission levels in a C# controller. Exceptions are handled with HTTP status codes that indicate the request was not allowed. In contrast, Powershell executes within the security context of the logged in user, and allows system-level changes even if not running escalated. If an injection flaw is exploited, the code would be executed in the web server's security context, not the user's. You may be surprised how much the IIS_USER (or other Application Pool service account) can do. For one, if the bad guy is executing in the context of a service account, they might be able to bring down your whole site with a single request by locking out that account or changing the password - a task that's much easier with a Powershell script than with compiled C# code.
Security Misconfiguration - likely vulnerable. A running script would require it's own security configuration outside whatever framework you are using for the Web API. Are you ready to re-implement something like OAuth Claims or ACLs?
Cross-Site Scripting - likely vulnerable. Are you echoing the script output? If you're not sanitizing input and output, the script could echo some Javascript that sends a user's cookie content to a malicious server, giving them access to all the user's resources. Cross site request forgery is also a risk if input is not validated.
Insecure Deserialization - Probably not vulnerable.
Using Components with Known Vulnerabilities - greatly increased vulnerability, compared to compiled. Powershell grants access to a whole set of libraries that would otherwise need explicit references in a compiled application.
Insufficient Logging & Monitoring - likely vulnerable. IIS logs requests by default, but Powershell doesn't log anything unless you explicitly write to a file or start a transcript. Neither method is designed for concurrency and may introduce performance or functional problems for shared files.
In short, 9 out of the top 10 Vulnerabilities may affect this implementation. I would hope that would be enough to prevent you making your script public, at the very least. Basically the problem is that you're using the tool (Powershell) for a purpose it wasn't intended to fulfill.
I run an self-hosted instance of BigBlueButton and signed up for Xirsys TURN server services because we need to serve clients behind (pretty restrictive) firewalls. Before I had been running my own instance of coturn, but as this led to problems recently, I thought I will got someone who does this for a living a try.
Now the configuration in BBB is explained here:
https://docs.bigbluebutton.org/2.2/setup-turn-server.html
Yet so far I completely failed to match the parameters I receive from Xirsys with what I have to put into the /usr/share/bbb-web/WEB-INF/classes/spring/turn-stun-servers.xml file in the place of the <turn.example.com> and <secret_value>.
Did anyone ever make this work? I did try and find a tutorial but also failed.
bbb_web, is returning this the turn uris. passwords to the html5 client, that the client is using in sip.js
so you can either get bbb-web to send valid username/passwords is same method is used, or modify the html5 client to make a Xirsys api call, to get access to the turn candidates.
Would need to look at api docs. twilio has a similar service.
regards,
Stephen
not the most elegant solution but the easiest one for me:
modify the final bbb js bundle to load the stunturn info from a fixed url in
e.g.
/usr/share/meteor/bundle/programs/web.browser/f30716b2b57e2862c4db2325 b7aac63f4622842b.js
the minified part should then look somewhat like:
const r=Meteor.settings.public.media,i='https://<yourbbburl>/html5client/stunturn.json',a=r.cacheStunTurnServers,s=r.fallbackStunServer;
and put either the static credentials or generated ones in a file stunturn.json besides the js bundle.
I have created a manifest for a Word add-in that refers to a web page that is not secured by https. I get errors in the Word host and can tell Word to temporarily accept this but cannot find how to tell it to ignore the warning on every launch.
It will actually be an issue in the Online versions of Office because the apps themselves are always https, and thus generate mixed content (both http and https) if your app isn't.
Also, it is generally a bad idea to have an unsecured add-in. You're allowing an application to read the documents you're working on, without https you'd never know if you're actually allowing a 'fake add-in' to read all your data and save it somewhere else.
Lastly, the Office store does not allow non-https add-ins at all, so if you're planning in distributing your app through the store you will definitely need SSL.
What are the error that you get in Wordhost? Word does normally not complain when a http:// address is used in a taskpane. Do you maybe have mixed content in the website?
I need to add Relying parties in ADFS everytime a new client comes on. I would like to automate this by just specifying either the url to the federation metadata or a file picker for the admin to load the federation metadata file.
I have been following the instructions on this site Adding a New Relying Party Trust
However I get the following error
ADMIN0120: The client is not authorized to access the endpoint
net.tcp://localhost:1500/policy.
The client process must be run with elevated administrative privileges.
not sure what I am doing wrong. I guess the bigger question is : is this the best way to set up Relying parties and Claims using code or should I use powershell commands?
This error doesn't means you have code issue. It is something related to the privilege. Test it by right mouse click the client and "Run as administrator" to see if it goes through.
As per your link, there are three ways:
Using the AD FS 2.0 Management console
Using the Windows PowerShell command-line interface
Programmatically using the AD FS 2.0 application programming interface (API)
All three are equally valid - the only difference is how much work you have to do for each e.g. the wizard is lots of mouse clicks.
What I do is set up the RP the first time via the wizard and then save the setup using PowerShell (Get RP, Get Claims etc.) and then use these to set up subsequent ones as you migrate from dev. to test. to staging etc.