Codebase I am working on has been analyzed by Checkmarx, and it came back with a report containing a "Stored XSS" issue. The issue states:
Method GetHomepageFilterByLocale HomepageRepo.cs gets data from the database, for the Select element. This element’s value then flows through the code without being properly filtered or encoded and is eventually displayed to the user in method GetProductsByFilterType HomepageController.cs. This may enable a Stored Cross-Site-Scripting attack.
Is there a standard recommended way to resolve this issue?
Please see below code snippets for the both mentioned methods.
HomepageRepo.cs
public HomepageFilter GetHomepageFilterByLocale(int localeId)
{
return _context.HomepageFilter.SingleOrDefault(x => x.LocaleId == localeId);
}
HomepageController.cs
GetHomepageViewModel() method is where the repository method is called.
[HttpGet]
public ActionResult GetProductsByFilterType(int locale, string filterType)
{
HomepageViewModel model = GetHomepageViewModel(locale, filterType);
if (model?.Products != null)
{
model.Products.ForEach(p => p.Name = HttpUtility.HtmlEncode(p.Name));
model.Products.ForEach(p => p.ImageUrl = HttpUtility.HtmlAttributeEncode(p.ImageUrl));
}
return Json(model, JsonRequestBehavior.AllowGet);
}
You should look at the vulnerability flow (to the right of the screen when you view the vulnerability) and see what objects are involved in this vulnerability.
You can also click on the little question mark sign ('?') on the right of the vulnerability name. it should tell you how to resolve it.
Finally, if you are still facing issues, you can click on the query viewer and preview what the query looks for exactly.
Now: from my own experience, xss vulnerabilities are easily fixed with HttpUtility.HtmlEncode method.
I'm thinking something like:
HttpUtility.HtmlEncode(_context.HomepageFilter.SingleOrDefault(x => x.LocaleId == localeId));
Related
I am new to building API's. My project contains three typical layers: controllers, services responsible for business logic, and repositories which are accessing data. Every request coming to my controllers have to go through some validation process before a specific action is performed. For an example, please inspect the code below:
[HttpPost]
public async Task<ActionResult<TicketDTO>> CreateTicketAsync([FromBody] CreateTicketDTO ticket)
{
try
{
if (ticket.Events == null)
{
return BadRequest(new {Message = _localizer["LackOfEventsErrorMessage"].Value});
}
var user = await _userService.GetUserByIdAsync(ticket.UserId);
if (user == null)
{
return NotFound(new { Message = _localizer["UserNotFoundErrorMessage", ticket.UserId].Value });
}
var invalidTicket = await _ticketService.CheckHasUserPlayedAnyOfGamesBeforeAsync(ticket);
if (invalidTicket)
{
return BadRequest(new { Message = _localizer["EventsRepeatedByUserErrorMessage"].Value });
}
var createdTicket = await _ticketService.AddTicketAsync(ticket);
if (createdTicket == null)
{
return BadRequest(new { Message = _localizer["TicketNotCreatedErrorMessage"].Value });
}
return CreatedAtAction(nameof(GetTicketById), new {ticketId = createdTicket.TicketId}, createdTicket);
}
catch (Exception ex)
{
return StatusCode(StatusCodes.Status500InternalServerError,
new
{
Message = ex.InnerException != null
? $"{ex.Message} {ex.InnerException.Message}"
: ex.Message
});
}
}
This is one of my controller methods. Before the ticket is saved to database, it has to pass few checks. The owner of the ticket must exist, if not i return user not found etc. The problem is I do not really like this way of validating requests. The method is messy, and not very readable. I would like to know what is a good approach to validate requests, and react properly if something wents wrong (for example return "UserNotFoundErrorMessage" if there is no user in a database, etc. single catch block doesn't solve my problem. I wouldn't also like to have multiple catch blocks there, it's also messy i think. Am i wrong?)
I wonder does the attached snippet violate some clean code rules or not? How the code should look like? What I am doing wrong?
All of this logic should be shuffled into your business layer, i.e. your services. The service methods, then, should return a "result" class, which is basically just a way of sending multiple bits of information back as the return, i.e. success/fail status, errors, if any, the actual result in the case of a query or something, etc. Then, you can simply switch on the error and respond accordingly.
As far as the catches go, especially the main one that simply returns a 500, use a global exception handler. Let the error bubble up from the action and rely on the global handler to return an appropriate response.
Like others have already pointed out, this does not seem half bad.
I can tell you as much that we have snippets of code that are 10 times the size of this. Tbh, this seems like small part compared to some modules i've seen in my company's codebase.
That being said, you could move a bit more logic away from the controller, and to other layers. For example, when getting a user by its Id, you can also throw a not found exception from your serviceclass if an user by that id does not exist. you have now stuffed everything into a controller, whilst it feels like this is more the resposibility of the service.
Another thing you could do is perhaps use middleware:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-3.1
You can create validation pipelines for your response.
I've also tried working with a validation pattern. In this case i would create some rules for checks, and applied these rules to stuff to validate. I then had a validator object that would take all the rules an prompt an appropriate output. This made the code cleaner and resuse better, however added some complexity and i ended up not using it. It was different than the rest of the codebase and therefore foreign to colleagues, and thus i had good argument not to use it.
Background
I have a central database my MVC EF web app interacts with following best practices. Here is the offending code:
// GET: HomePage
public ActionResult Index()
{
using (var db = new MyDbContext())
{
return View(new CustomViewModel()
{
ListOfStuff = db.TableOfStuff
.Where(x => x.Approved)
.OrderBy(x => x.Title)
.ToList()
});
}
}
I also modify the data in this database's table manually completely outside the web app.
I am not keeping an instance of the DbContext around any longer than is necessary to get the data I need. A new one is constructed per-request.
Problem
The problem I am having is if I delete a row or modify any data from this table manually outside the web app, the data being served by the above code does not reflect these changes.
The only way to get these manual edits of the data to be picked up by the above code is to either restart the web app, or use the web app to make a modification to the database that calls SaveChanges.
Log Results
After logging the query being executed and doing some manual tests there is nothing wrong with the query being generated that would make it return bad data.
However, in logging I saw a confusing line in the query completion times. The first query on app start-up:
-- Completed in 86 ms with result: CachingReader
Then any subsequent queries had the following completion time:
-- Completed in 0 ms with result: CachingReader
What is this CachingReader and how do I disable this?
Culprit
I discovered the error was introduced elsewhere in my web app as something that replaced the underlying DbProviderServices to provide caching, more specifically I am using MVCForum which uses EF Cache.
This forum's CachingConfiguration uses the default CachingPolicy which caches everything unless otherwise interacted with through the EF which was the exact behavior I was observing. More Info
Solution
I provided my own custom CachingPolicy that does not allow caching on entities where this behavior is undesirable.
public class CustomCachingPolicy : CachingPolicy
{
protected override bool CanBeCached(ReadOnlyCollection<EntitySetBase> affectedEntitySets, string sql, IEnumerable<KeyValuePair<string, object>> parameters)
{
foreach (var entitySet in affectedEntitySets)
{
var table = entitySet.Name.ToLower();
if (table.StartsWith("si_") ||
table.StartsWith("dft_") ||
table.StartsWith("tt_"))
return false;
}
return base.CanBeCached(affectedEntitySets, sql, parameters);
}
}
With this in place, the database logging now always shows:
-- Completed in 86 ms with result: SqlDataReader
Thanks everyone!
Hi i am trying to combine a C# webservice in azure with a get and a post at the same time, the idea is to get the details of a CD by the uniqueCDcode and the webservice outputs just the json information AND the uniqueCDcode needs to be stored in a different table CDClicked to i get a list of all the clickedCD's so i am able to take the last 50 as for trending etc. but don't really seem to get it to work. This is what i have so far
//// WS# 00002 GET THE ALBUM DETAILS
[Route("api/Music/Album/{uniqueCDcode}")]
public HttpResponseMessage GetAlbum(int uniqueCDcode)
{
return Request.CreateResponse(HttpStatusCode.OK,
new { AlbumMusic = db.Music
.Where(am => am.uniqueCDcode == uniqueCDcode);
db.CDClicked.Add(uniqueCDcode);
}
You need to retrieve your record/do the save, then return the response. The Add() method call to dbContext (second part) isn't working because the return statement is returning a value first, and then stopping the execution of your service, so it never gets to the second part. Your logic needs to be done before the return statement.
For example:
[Route("api/Music/Album/{uniqueCDcode}")]
public HttpResponseMessage GetAlbum(int uniqueCDcode)
{
db.CDClicked.Add(uniqueCDcode);
return Request.CreateResponse(HttpStatusCode.OK,
new { AlbumMusic = db.Music
.Where(am => am.uniqueCDcode == uniqueCDcode )});
}
You also had some formatting issues in the code. Your braces and parens didn't match up (at least in the code that you pasted into SO.) I corrected in my answer below.
Note: I can't test the code at the moment due to hurricane-related issues, but this is the general concept to get you going again.
I have this code in my WebApiConfig.cs file and within the Register method:
var jsonFormatter=config.Formatters.JsonFormatter;
jsonFormatter.UseDataContractJsonSerializer = false;
jsonFormatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();
And yet despite this (and I did make sure this code was definitely being executed by using Debugger.Launch()) it is still outputting all my Json in Pascal Case.
Here is the code in the action method:
[HttpGet]
[Route("Details")]
public IHttpActionResult Details() {
using (var context = new Security.Context()) {
var user = context.Users.Current;
if (user == null) { return Json((object)null); }
return Json(user);
}
}
I can't see what I'm doing wrong, is there something I am missing?
Instead of returning IHttpActionResult, return the concrete type (User in your case). This way, you'll avoid lots of potential issues, including serialization, testability, and content negotiation as well.
So maybe someone can explain this but I found out that using the ApiController.Json method does not appear to use any of the global formatters (I removed them all and this method still functioned and returned valid Json albeit in Pascal Case).
When I use the ApiController.Ok method, this does use the global formatters and any settings applied to them, like the CamelCasePropertyNamesContractResolver.
So my solution is to use "Ok" instead of "Json"...but why they are different I don't know...
I am administrator of a small practice project web application, AngularJS front-end pulling its back-end data from a C#/.NET WebAPI, and I'm handling security using the SimpleMembershipProvider.
I suspect that the way I implemented said security is not the best (I'm told ASP.NET Identity is now the way to go?) but that's another question altogether.
The issue that I'm very bewilderingly running into is that I get occasional reports that on a given page load to display a particular user's data, it returns somebody else's. Reloading the page fixes the issue (evidently) and I haven't been able to duplicate the scenario myself, or figure out anything particularly consistent in the users to which this happens.
None of the information being displayed is at all sensitive in nature (the app's just a friendly front end for an already public third-party API) so I'm not in panic mode about this, but I am both concerned and confused and want it fixed.
Here is what one of my API controller endpoints looks like:
[Authorize]
public class UserController : ApiController
{
private static int _userId;
private readonly IUserProfileRepository _userProfileRepository;
public UserController()
{
_userProfileRepository = new UserProfileRepository(new DatabaseContext());
_userId = WebSecurity.GetUserId(User.Identity.Name);
}
public UserProfileDto Get()
{
return _userProfileRepository.GetUserProfileById(_userId).ToDto();
}
}
Any feedback on where I might be going wrong here or what might be causing the intermittant inconsistency would be very much appreciated. (Laughter also acceptable if the way I handled this is just really bad. :P )
Static class fields are shared by all instances/threads of the same AppDomain (in your case - process). Different http requests are processed by threads running in parallel. Any two threads running [almost] at the same time may (will) change the value of _userId. You are assigning _userId in the constructor of your controller, and a new instance of this controller is created for each http request that is to be responded to by UserController. Therefore, this assignment will happen multiple times.
You will have hard time replicating this problem, since you are a single user testing the code, hence there are no overlapping request threads.
Remove static specifier from the _userId field declaration of the controller class.
Note: make sure that DatabaseContext is disposed of. One place that can be used for this is the overriden Controller.Dispose.
Change the Get to retrieve the user id rather than from a static variable:
public UserProfileDto Get()
{
return _userProfileRepository.GetUserProfileById(WebSecurity.GetUserId(User.Identity.Name)).ToDto();
}