I have page that with textbox's for first and last name.
When i test the page and update the last name with Doe%uff1cscript%uff1ealert%uff0812345%uff09%uff1c/script%uff1 using interceptor in proxy tool like BURP suite the last name gets stored as <script>alert（12345）</script> in the database.
I have tried to use microsoft antixss library but that did not work. Below is the code I used:
Dim Lname As String = Microsoft.Security.Application.Encoder.HtmlEncode(txtLName.Text)
Does anyone have a suggestions one how I can prevent this?
Simply HTML encode on output, not when it is stored.
e.g. < becomes <, & becomes &.
See the OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet for further details.
In .NET you can use Server.HTMLEncode or <%:myVar %> in views to do this.
Related
I would like to pass a date string to a web service for testing, using a browser. I've tried Chrome and Firefox and both error out with this:
Server Error in '/' Application.
A potentially dangerous Request.Path value was detected from the client (:
The web service (RESTful) is accessed like this:
http://localhost:52936/Accounts/mod_date/2015-05-13T15%3A15%3A19
I've tried enclosing the date in quotes, but get the same error. Is this possible?
Try a QueryString Parameter
Since you are just performing testing, you should be able to pass your stringified DateTime value as a querystring parameter and it should avoid your service throwing a fit :
/Accounts/mod_date?yourDateParameterName=2015-05-13T15:15:19
Or if you wanted a more in-depth approach, you could consider using a suggestion like the one mentioned in this related discussion.
Explicitly Allow : Characters
Scott Hanselman covers the idea of explicitly allowing certain characters to be passed to a service via a URL in this blog post. It basically allows you to define which values are considered "dangerous" when passed in and would simply involve you changing the requestPathInvalidCharacters setting within the web.config of your application from :
<httpruntime requestvalidationmode="2.0">
requestPathInvalidCharacters="<,>,*,%,:,&,\"
/>
</httpruntime>
to :
<!-- Removes the colon ':' as a dangerous parameter -->
<httpruntime requestvalidationmode="2.0">
requestPathInvalidCharacters="<,>,*,%,&,\"
/>
</httpruntime>
This is obviously very controversial stuff and may not be useful for all scenarios, but it is an option.
Consider Postman (for Testing)
Additionally for testing purposes, you might consider using a service like Postman, which is ideal for performing this type of API testing.
I am invoking Sharepoint's List Web services and using the getListItems() method. In particular, I am keen on specifying a CAML query because I really want it to just retrieve one item that I am specifically interested in. This I am doing by specifying a query in my XML string, in varying degrees of combinations, either by specifying the EncodedAbsUrl, the LinkFileName, the URL or the FileRef, with most results returning 0.
The XML query looks like this :
<?xml version="1.0" ?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body><GetListItems xmlns="http://schemas.microsoft.com/sharepoint/soap/"><listName>{5cbc4407-3851-4e00-964a-bb7e9b430f9f}</listName> <viewName></viewName> <rowLimit>1000</rowLimit> <webID></webID>
**<query><Query><Where><Eq><FieldRef Name = "FileRef"/><Value Type = "Text">"/Shared%20Documents/Ashish/Word_feb27.doc"</Value></Eq></Where></Query></query>**
<viewFields><ViewFields><FieldRef Name="FSObjType"/><FieldRef Name="LinkFilename"/><FieldRef Name="UniqueId"/><FieldRef Name="FileRef"/><FieldRef Name="FileRef"/><FieldRef Name="EncodedAbsUrl"/><FieldRef Name="FileSizeDisplay"/><FieldRef Name="_UIVersionString"/><FieldRef Name="_owshiddenversion"/></ViewFields></viewFields></GetListItems> </S:Body></S:Envelope>
Without the tags this Soap request does infact work, and it retrieves all the items that area available in the List. The frustration begins when i specify the query tag. In particular the Following combinations have been attempted by me
FieldRef.name = {LinkFileName, EncodedAbsUrl, URL,FileRef} and Value.type = {Text, URL}
Either they yield results with no 0 fields in it or they return internal errors. I figure, this is a syntactical issue and would rather shoot this question to you guys who have probably dunnit in the past to see where I am possibly messing it up.
Thanks
I would recommend using CAML Query Builder and Fiddler. Query builder can connect SP using Web services and you can build the query with that. After you got your expected results, capture the Web service request with Fiddler and use it :)
BTW: Have you considered using Sharepoint Client Object model? You do not have to worry about SOAP messages.
Remove the <query><Query> tags.
I have been developing an MVC application locally (IIS Express) and deploing to IIS 7.5 periodically in order to test.
I have just added a new named Route to my Global.asax.cs file:
routes.MapRoute(
"MyCustomRoute", // Route name
"{documentID}/{year}", // URL with parameters
new { controller = "Documents", action = "CurrentVersion", year = DateTime.Now.Year }, // Parameter defaults
new { documentID = #".*\d+.*" } // Regex matches only where documentID contains numerical values.
);
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Documents", action = "Index", id = UrlParameter.Optional } // Parameter defaults
);
I have set up a Html.RouteLink using "MyCustomRoute" and all works well on my local machine.
However, when I run this on the Web Server, Html.RouteLink is generating an empty link. In addition, if i enter the URL directly into the browser, it gives a 404.
It seems as if the Route has not registered. What am I missing?
It's impossible for us to debug your route without seeing the code, and if you use the right tools, it will be very easy for you to see what's going on and what is being matched.
Phil Haack built an excellent open source tool called RouteDebugger. You can get it through NuGet and read about how to use it at http://haacked.com/archive/2011/04/12/routedebugger-2.aspx . A more robust version of this project is available as RouteMagic and is at Codeplex and git. Details at this blog post
UPDATE
Based on your regex, you're documentID is not being matched due to greediness. .* will match everything, so you it will never have the opportunity to match \d+, because the preceding pattern will cannibalize all matches. You can read about regex greediness and laziness at http://www.regular-expressions.info/repeat.html .
UPDATE 2
Regexes are probably the thing I'm worst at programming, and the only reason I recognized that issue is because I am so bad at them that I've run into the same issue about a million times. That being said, I think #"(.*?)(\d+?)(.*?)" will do the trick. It should work without any of the parentheses as well (like #".*?\d+?.*?"), but I like to keep them in there for readability (mostly because I'm so bad at them).
I've been trying to programmatically reproduce the behavior of editing a Content Type's field properties in the SharePoint site management screen and selecting the "Required" radio button with no sucess using the WSS 3.0 web service's Webs.asmx "UpdateContentType" method.
The first difficulty was the issue with the MSDN documentation that said fields should be of a FieldRef type when in fact they need to be of a Field type (reference). Adding fields and deleting fields works fine after the fix, but updating fields seems to not function at all. (It should also be noted that I followed the recommendation on the previous link to use Method="2" for updating fields but it changes nothing, and using Method values other than 1 for adding or other than 3 for deleting also function correctly).
Here's the web service call (slightly modified with strings instead of XmlNode objects for readability):
SharePointWebServices.Webs webService = new SharePointWebServices.Webs();
webService.Url = "http://mysharepointserver/site";
webService.UseDefaultCredentials = true;
webService.UpdateContentType(
#"0x01005A089D9EC8A382458FB1F6C72096D52A",
#"<ContentType />",
#"<Fields />",
#"<Fields><Method ID=""1""><Field Name=""SomeField"" ID=""{8a4803c4-6545-4a7a-804d-237eebff0ce3}"" Required=""TRUE"" Hidden=""FALSE"" ReadOnly=""FALSE"" PITarget="""" PIAttribute="""" PrimaryPIAttribute="""" Aggregation="""" Node="""" /></Method></Fields>",
#"<Fields />");
After the call, the field is still Required="FALSE".
A quick look into the stssoap.dll assembly indicates that the "Required" property is apparently ignored during the update process. Is this normal behavior? If so, what is the recommended method for programmatically changing the "Required" field from client code (not executing on the SharePoint server)?
Any help would be greatly appreciated.
I've investigated this and found the same thing. I also tried adding the attribute Cmd="Update" to the Method element without success. This example of how to use UpdateContentType was helpful too.
I don't believe you will be able to do this with the out-of-the-box SharePoint services. You've verified from looking at stssoap.dll that this doesn't appear to work correctly. Another 'client'-style option is to use RPC methods but none appear to provide functionality for content types at all.
The web services are particularly frustrating because this type of not-so-edge case regularly comes up. It is very rare that I consider using them because of the time wasting involved with their limitations.
Do you have any option of deploying custom code to the server? You could develop this functionality using the object model and wrap it in your own custom web service (there is a walkthrough here) quite easily.
Here is an example adapted from Gabe Wishnie that does what you require:
SPContentType myContentType = myWeb.ContentTypes["myContentType"];
string internalName = myContentType.Fields["fieldToUpdate"].InternalName;
myContentType.FieldLinks[internalName].Required = false;
myContentType.Update(true);
Sorry this isn't more helpful but it's a common story when using the WSS 3.0 / SharePoint 2007 web services.
Even famous sites like Twitter are suffering from XSS vulnerability, what should we do to prevent this kind of attack?
The #1 Thing you can do is set your cookies to HTTP Only ... which at least protects against session cookie hijacking. Like someone stealing your cookie when you are likely admin of your own site.
The rest comes down to validating all user input.
RULE #0 - Never Insert Untrusted Data Except in Allowed Locations
RULE #1 - HTML Escape Before Inserting Untrusted Data into HTML Element Content
RULE #2 - Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
RULE #3 - JavaScript Escape Before Inserting Untrusted Data into HTML JavaScript Data Values
RULE #4 - CSS Escape Before Inserting Untrusted Data into HTML Style Property Values
RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL Attributes
Very lengthy subject discussed in detail here:
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
http://www.owasp.org/index.php/Cross_site_scripting
XSS is only one of many exploits and every web dev should learn the top 10 OWASP by heart imho
http://www.owasp.org/index.php/Top_10_2007
Just like you can make SQL injection a non-issue by using prepared statements, you can make XSS non-issue by using templating engine (DOM serializer) that does similar thing.
Design your application so that all output goes via templating engine. Make that templating engine HTML-escapes all data by default. This way you'll have system that's secure by default and does not rely on humans (and rest of the large system) being diligent in escaping of HTML.
I don't what you write your code with, but if your use asp.net, you are partly covered.
asp.net has what they call request validation that when enabled, it prevent malicious script to be introduced via user input.
But sometimes, you'll have to allow some kind of text editor like the one you typed in this question. In this case, you'll have to partly disable request validation to allow some "rich text" html to be input by the end user. In this case you will have to build some kind of white list filtering mechanism.
FYI, I don't know about others but Microsft has library called Anti-Xss.