0

I've been studying about common injection related problems. Is it possible to embed some filtering mechanism to prevent injection client side? For example checking address bar URL for malicious added parameters, or checking user input forms on submission.
I am not questioning whether this measure is 100% effective or needed or not. I want to know if this is technically possible and feasible.

Improve this question

2 Answers 2

Reset to default
3

Yes it's possible to add something like this on the client side, but it would not be effective. I wouldn't waste your time adding this type of protection to your client side. Since it is on the client side, a malicious user can (and will) bypass it immediately using an HTTP Proxy or something similar.

I would recommend give the book, The Web Application Hacker's Handbook a read. This goes into detail about how a malicious user will attack your site and points you to free tools that will allow you to attack a test site you control in the same manner that a hacker would. Actually doing this will open your eyes to how web security really works.

Improve this answer
1
  • Thanks for the answer, I was interested in this topic because I'm considering some hypothesis regarding a platform using a custom browser that somewhat differs from standard browser use scenario. I will also take a look to the book, thanks for the hint.
    – Matteo Grimaldi
    Commented Jun 10, 2014 at 15:55
0

There are two fallacies:

  • In case of an injection attack against the server, the client itself is the attacker. In other words, you're asking the attacker to prevent their own attack. This obviously makes no sense. Even if the person using the browser is actually on your side and only lost control of their browser (due to XSS, CSRF or whatever), it's safe to assume that the client will skip any security actions you ask for.

  • You seem to think there's a kind of one-size-fits-all procedure to magically make the input “safe”. But injection attacks depend on the exact context. Are we talking about HTML injection? SQL injection? Shell injection? Each of those work differently and require different ways of protection. The only valid way to handle this is to prepare the data server-side for each specific context.

Improve this answer
3
  • You obviously didn't read the question well enough. I've not asked if that would be flawless, I've asked if it is just technically possible to, at least, grant a minimum additional level of mitigation client side by the use of a custom browser, even if poorly.
    – Matteo Grimaldi
    Commented Jun 10, 2014 at 20:56
  • I don't think you've understood the answer. I'm not talking about “poor protection” (whatever that means). I'm saying that your approach doesn't provide any protection at all. You're delegating protection to the very entity you're trying to protect against. This is not just poor, it simply makes no sense. That's the answer, and you'll have a hard time finding a different opinion.
    – Fleche
    Commented Jun 10, 2014 at 22:12
  • I'll try to make this clear. This situation would make no sense to you because the scenario that drove my question requires users to use only a customized browser, that does not allow to use URLs in any way and only accesses a controlled set of web applications (that could be anyway vulnerable to injection attacks). I'm well aware there are a lot of ways to inject code in a vulnerable web application, what I wanted to know is just if it is, at least, technically possible to mitigate the risks client side, leave the sense part to me.
    – Matteo Grimaldi
    Commented Jun 11, 2014 at 8:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .