Solved

why do i keep getting "A potentially dangerous Request.Form value was detected from the client"

Posted on 2014-11-04
2
75 Views
Last Modified: 2016-06-22
i have a web.config, which will show a SALM login page. It will successfully login. but after that i will get the above error.

Done:
added :  <pages validateRequest="false"
tested : requestValidationMode="2.0"
added on aspx page : <%@ Page Language="C#" validateRequest="false"

still the same error.

web.config re-directs to an aspx page:

 <wsFederation passiveRedirectEnabled="true" issuer="https://login.website.nl" realm="http://localhost/" requireHttps="false" reply="http://localhost/Test.aspx"/>

Open in new window


Test.aspx directly runs fine. It's just that after loggin in, i will get the above error.

Any my landing pages looks really basic:

<%@ Page Language="C#" validateRequest="false" AutoEventWireup="true"%>

    <title>SAML authentication landing page</title>
</head>
<body>
    <h1>SAML authentication landing page</h1>

</body>
</html>

Open in new window


I don't see any request form there.

Anyone can help?
0
Comment
Question by:A. Amien
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
2 Comments
 
LVL 63

Accepted Solution

by:
btan earned 500 total points
ID: 40423758
In fact, "<" is not inherently dangerous, its only dangerous in a specific context: when writing unencoded strings to HTML output (because of XSS). In other contexts different substrings are dangerous, e.g. if you write an user-provided URL into a link, the substring "javascript:" may be dangerous.

Also the single quote character on the other hand is dangerous when interpolating strings in SQL queries, but perfectly safe if it is a part of a name submitted from a form or read from a database field.

You can't filter random input for dangerous characters, because any character may be dangerous if the request is ill intended . It is better to encode at the point where some specific characters may become dangerous because they cross into a different sub language where they have special meaning. Most refer it as input validation checks...

E.g.  When you write a string to HTML, you should encode characters that have special meaning in HTML, using Server.HtmlEncode.  When you are sure you HTML-encode everywhere you pass strings to HTML, then set validateRequest="false". Not sure for the various .NET version especially v4 like some has to also add <httpRuntime requestValidationMode="2.0" /> to web.config...

E.g. If you pass a string to a dyamic SQL statement, you should encode different characters (or have the framework handle this using prepared statements or equivalent).
0

Featured Post

Webinar May 25: Cloud Security Strategies for SMBs

Small and mid-sized businesses are a driving force behind cloud adoption, and it’s no wonder: cloud benefits are BIG.  But for all the convenience that moving to the cloud provides, where does security come into play?

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Phishing is at the top of most security top 10 efforts you should be pursuing in 2016 and beyond. If you don't have phishing incorporated into your Security Awareness Program yet, now is the time. Phishers, and the scams they use, are only going to …
Transferring data across the virtual world became simpler but protecting it is becoming a real security challenge.  How to approach cyber security  in today's business world!
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.

738 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question