如何以正确的大小写获取 WebResource.axd 查询字符串?

发布于 2024-07-24 07:33:05 字数 1921 浏览 1 评论 0原文

我从 QueryString["path"] 获取用于缩小和压缩的 css 文件,对于我自己的 css 文件(如 main.css),一切正常。 但是当我尝试访问网络资源文件时,我收到 500 错误。 webresource.axd 之后的参数区分大小写,我从小写的 QueryString["path"] 接收它。

这是我从 QueryString["path"] 得到的信息:

http://localhost/test/webresource.axd?d=-phgrn6r6zgehvbi697-bxvkl_gidnplxpdeukz5kncgr9hvnfvttpgykwyw05cda-nymtz9od_bbww3ynzxha2&t=633789305460522066

上面的链接生成错误:CrypgraphicException:填充无效且无法删除。

正确的链接是这样的:

http://localhost/test/WebResource.axd?d=-pHGRn6r6ZGehvBI697-BxVKl_GIdNPlxPdEUKZ5KNcGR9hvnfVtTpgyKwYw05cDa-NymTz9OD_bBwW3ynZXhA2&t=633789305460522066

唯一的区别在于大小写。 CryptographicException 似乎很常见,但即使设置 machineKey 也没有解决问题。 有关如何在原始情况下获取 webresource.axd 的任何提示吗?

编辑

请求代码:

public void ProcessRequest(HttpContext context) {
    Control c = new Control();
    string root = context.Request.Url.GetLeftPart(UriPartial.Authority);
    string path = context.Request.QueryString["path"];
    string content = string.Empty;

    if (!string.IsNullOrEmpty(path)) {
        if (context.Cache[path] == null) {
            List<string> dependencies = new List<string>();
            string[] styles = path.Split(new string[] { "," }, StringSplitOptions.RemoveEmptyEntries);
            foreach (string style in styles) {
                content += RetrieveStyle(root + c.ResolveUrl(style)) + Environment.NewLine;
                dependencies.Add(context.Server.MapPath(style));
            }
            content = StripWhitespace(content);
            context.Cache.Insert(path, content, new CacheDependency(dependencies.ToArray()), Cache.NoAbsoluteExpiration, new TimeSpan(DAYS_IN_CACHE, 0, 0, 0));
        }
    }
}

当我调用时,它在 RetreiveStyle 中崩溃:

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())

I am getting the css files for minifying and compressing from QueryString["path"] everything works correctly for my own css files like main.css. But when I try to acess the webresource files I receive a 500 error. The parameter which comes after the webresource.axd is case sensitive and I receive it from QueryString["path"] lowercase.

This is what I get from QueryString["path"] :

http://localhost/test/webresource.axd?d=-phgrn6r6zgehvbi697-bxvkl_gidnplxpdeukz5kncgr9hvnfvttpgykwyw05cda-nymtz9od_bbww3ynzxha2&t=633789305460522066

The above link generate error : CryptographicException: Padding is invalid and cannot be removed.

This is what the correct link look like :

http://localhost/test/WebResource.axd?d=-pHGRn6r6ZGehvBI697-BxVKl_GIdNPlxPdEUKZ5KNcGR9hvnfVtTpgyKwYw05cDa-NymTz9OD_bBwW3ynZXhA2&t=633789305460522066

The only difference is in the case. CryptographicException seem to be common but even setting machineKey didn't fixed the problem. Any hint on how could I get the the webresource.axd in the original case?

EDIT

Code was requested :

public void ProcessRequest(HttpContext context) {
    Control c = new Control();
    string root = context.Request.Url.GetLeftPart(UriPartial.Authority);
    string path = context.Request.QueryString["path"];
    string content = string.Empty;

    if (!string.IsNullOrEmpty(path)) {
        if (context.Cache[path] == null) {
            List<string> dependencies = new List<string>();
            string[] styles = path.Split(new string[] { "," }, StringSplitOptions.RemoveEmptyEntries);
            foreach (string style in styles) {
                content += RetrieveStyle(root + c.ResolveUrl(style)) + Environment.NewLine;
                dependencies.Add(context.Server.MapPath(style));
            }
            content = StripWhitespace(content);
            context.Cache.Insert(path, content, new CacheDependency(dependencies.ToArray()), Cache.NoAbsoluteExpiration, new TimeSpan(DAYS_IN_CACHE, 0, 0, 0));
        }
    }
}

It crashes in RetreiveStyle when I call :

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

毅然前行 2024-07-31 07:33:05

罪魁祸首看起来像是生成“路径”查询字符串 csv 的代码或该源与处理程序之间的某些硬件或过滤器。

如果处理程序请求的来源是浏览器,则通过查看源或 firebug 处理程序 url 是什么样子? 已经是小写了吗?

接下来,您是否在 IIS 管道中注册了任何模块等?

The culprit looks like the code that is generating the “path” querystring csv or some hardware or filter between that source and your handler.

If the source of handler request is a browser what does the handler url look like through view source or firebug? Is it lowercase already?

Working forward from that, do you have any modules etc registered in you IIS pipeline?

墨落成白 2024-07-31 07:33:05

我没有答案,但我们遇到了类似的问题,我有一些需要补充的内容,这可以帮助识别问题。
所以,事情是这样的:

我们有一个 iHTTPHandler(我们称之为 Login.ashx),它接受 GET 请求,其中包含一个 base64 格式的令牌。
然后使用 Rijndael 算法对该令牌进行解密。

此过程大部分时间都在工作,但是,在上个月,我们有几个请求由于 System.Security.Cryptography.CryptographyException: Padding is invalid and can not be returned. 错误而失败。 在我们的例子中,当令牌(base64 字符串)为小写并且无法解密时,会引发此错误。

在查看日志和活动记录后,我可以看到特定用户会尝试通过 Login.ashx 来到我们这边,并且请求将由于相关错误而失败。 请求的整个查询字符串(不仅仅是令牌)包括名称和值都是小写的。 然后,同一用户会在几分钟后尝试登录,并且能够登录,因为查询字符串未转换为小写。

所以,我感觉这个问题可能与浏览器有关。 我不确定代理是否会影响这一点。

其他信息:
服务器变量中没有捕获浏览器信息。
ALL_HTTP 和 ALL_RAW 变量几乎没有数据:

  • ALL_HTTP HTTP_CACHE_CONTROL:无缓存 HTTP_HOST:我们的服务器名称
  • ALL_RAW Cache-Control:无缓存 Host:我们的服务器名称

还有没有 HTTP_REFFERER。

我尝试用不同的浏览器(Safari3、Chrome1、Opera9.2、IE6、7、8、Firefox3)重现此问题,但没有成功。

我们有一个网络农场,有 10 台配置相同的服务器(至少我希望它们是),

如果我取得任何进展,我将添加更多信息。

I do not have an answer but we have experienced a similar problem and I have a few things to add, which could help identifying the issue.
So, here it goes:

We have an iHTTPHandler (lets call it Login.ashx) that accepts a GET request, which contains a token in base64 format.
The token is then decrypted using Rijndael algorithm.

This process is working most of the time, however, in the last month we had several requests that failed due to System.Security.Cryptography.CryptographicException: Padding is invalid and cannot be removed. error. This error is raised in our case when a token (base64 string) is in lowercase and cannot be decrypted.

After going through logs and activity records I can see that a particular user would attempt to come to our side via Login.ashx and the request would fail due to the error in question. The whole querystring of the request (there is more than just token) including names and values is in lowercase. Then the same user would attempt a login a few minutes later and is able to get in because the querystring was not transformed to lower case.

So, I have a feeling that the issue could be browser related. I am not sure if proxy could affect this.

Additional info:
There is no browser information captured in the server variables.
ALL_HTTP and ALL_RAW variables have almost no data:

  • ALL_HTTP HTTP_CACHE_CONTROL: no-cache HTTP_HOST:our server name
  • ALL_RAW Cache-Control: no-cache Host: our server name

There is also no HTTP_REFFERER.

I have tried to replicate this issue with different browsers (Safari3, Chrome1, Opera9.2, IE6,7,8, Firefox3) with no luck.

We have a web farm with 10 servers configured identically (at least I hope they are)

I will add more info if I get any progress.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文