I am currently trying to create a safe login that only deals with username and passwords.
I've been reading about ways to prevent injection attacks, and C14N / Whitelist validation seems like a common practice. However, I can't figure out exactly how to canonicalize then validate user input.
My login is in a JSP page, which then processes the input through an httpservlet and checks if the user input matches the one in the database.
I have a few questions :
How do I canonicalize? Is there existing tools for me to use or do I have to create my own version?
Where do I canonicalize and validate - in the JSP page or Java servlet?
Do I need to whitelist validate, or is sanitization good enough for user input (usrname/pw)?
Are there tutorials / examples of the actual implementation so I can further understand this?
Theoretically, it all makes sense. But all the web docs that I am viewing don't explain how to do it.
Related
I have plenty of controllers and I want to validate all of parameters submitted in forms against XSS attacks. Instead securing each controller separately I would like to have one component that works as interceptor for all submitted forms and checks the parameters submitted.
I wrote a Filter that uses antisamy for correcting values of parameters but it works too good. I mean it escapes everything, even rich content that should not be escaped.
Sanitizing user inputs with Spring MVC framework
https://jeevanpatil.wordpress.com/2011/07/22/prevention_of_xss/
Therefre I need some solution to escape concrete parameters in controlers, do u know any solution ? I plan to create annotation next to parameters in every method in controller, for example #XSSEscaped, then only those parameters would be escaped.
HTML encoding at the time of input can corrupt the data. It may still not be secure because data inserted into an attribute, stylesheet, or script could still execute code even with HTML encoding. It may not cover all the data on the page as some values might not have come through the controller, or could have been modified since then.
There are many ways to bypass input filters (see XSS Filter evasion cheatsheet). The RequestWrapper in the linked answer for example filters out eval(), but pass in e<script></script>val() instead and you get eval() as output again. Fix that, then they'll be something else.
HTML encoding is the the responsibility of the view layer. This is where you can make sure all the data used on the page is encoded appropriately for the context where it's used. XSS is prevented by following the rules at the Cross Site Scripting Prevention Cheatsheet. Templating systems like Thymeleaf will do HTML encoding by default of its values.
I Know, we can use encodeForHTML for HTMl and encodeForJavascript for javaScript.
There is a Cross-Site Scripting: "Reflected fortify scan problem" in my code
String errorDesc = HttpServletRequest.getParameter("error_description");
I have to validate this using Encoder but I am confused to use which one should i use between them. As we do not know the return type of HttpServletRequest.getParameter.
1. org.owasp.esapi.Encoder.encodeForHTML
2. org.owasp.esapi.Encoder.encodeForJavaScript
What we have here dear asker is a rather common misunderstanding about the differences between output encoding--which is what you're working with when you look at the Encoder calls, and input validation, which is a completely separate operation that has little to do with the Encoder class.
The Encoder methods you're dealing with here are to be used only when you're presenting data to a user, and only for the correct context. For example, if the application is a "Single Page Application" (SPA) then very likely you're just going to want to ensure that the output is encoded for JavaScript as the client-facing framework will almost certainly be JavaScript.
If you were using an older style of application, then you would encode for HTML anytime you were going to place data between <some_tag> data </some_tag>.
XSS requires you to understand one thing for every variable in your application: Its data flow, from when the value is generated (Server, User, DB, etc.) and understand all of the transformations it might undergo as it traverses to the user and back to the system. If the value starts in the browser, it will enter into some kind of Controller on the backend, and before you process the value you'll whitelist validate it--ESAPI has a validator class--and then if it passes validation you'll ensure that the database will only treat it as data (PreparedStatement, or through use of an ORM framework's utilities.) Best practice is to
Canonicalize the data
Validate against the canonicalized value
If valid, discard the canonicalized value and store the original data
If used properly, the Validator class is defaulted to help you do this.
The methods you're asking about in this question are for instances where user input is being sent back to the browser, either from the database or from a previous request in your session that hasn't yet been persisted.
The main difference is how the output encoding is done. Encoder.encodeForHTML() does HTML entity encoding via the org.owasp.esapi.codecs.HTMLEntityCodec class, whereas Encoder.encodeForJavaScript() uses JavaScript's backslash encoding via org.owasp.esapi.codecs.JavaScriptCodec.
Which one you choose depends on the context of how your "error_description" parameter will be rendered in your application. If it is rendered between HTML tags, use encodeForHTML(), if you are rendering it in purely a JavaScript context, use encodeForJavaScript(). Refer to https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html for a more thorough explanation of all this.
I'm writing the back end for a web app in Spring. It uses Rest to communicate with the front end. The front end is browser based, so it can't contain a private key.
I've been trying to figure out what type of security I need to meet the following conditions:
1) The user logs in and I create a token that corresponds to a user object
2) I reply to the login request with this token
3) the token is attached by the front end to every request that I get so that I know what user is making that request.
Whenever I read up on Spring security I find two things, which are oauth2 and basic authentication, which I keep seeing people say is insecure. It seems like I can accomplish what I want with oath2, but it gets really confusing when I actually try to implement it.
What I want seems simple enough that I could just do all the work myself, but that seems like a terrible idea, since I have no experience with security. Could I, for example, have a local map of authentication tokens to user objects and redirect any request that has an invalid token to a login page? Taking into account repeated invalid request and expiry of tokens over time.
Or would I be missing a bunch of important security features by doing this? What specific words can I research to answer some of these questions on my own?
I am a beginner in the world of ACL coding.I have no prior knowledge of filters and other concepts and cannot learn that because of time constraints.So I found an alternative way to implement ACL.
I have only 3 users suppose user,admin and sys.
So I just create jsp pages starting with the respective user types and the name of the page.
eg:- "userCheckStatus.jsp" and "sysCreateUser.jsp"
And then i check whether the usertype which is stored in the session matches with the respective page the user is trying to access. I just want to know that is this a good practise and will it provide me with the thing which I am trying to achieve. If not then what is lacking in the above method and please advise me for the same.
Thanks in advance!!!
Your approach may work. One drawback is if you change your mind and you will want to give access rights to another user or introduce new role, you will have to rewrite it completely. For example you will have to find all references to that jsp and fix the links. If user bookmarked the jsp, it will be not found anymore. Some kind of indirection (mapping access to jsp in configuration file) would be better.
Standard servlet security is not so hard to try. See Oracle documentation. The good news is that servlet API has direct support for it.
i want to protect my website form xss, and i want to assure that all my data are correct and consistent, so i don't want to allow to add any scripts to my db, that's because my data may be used by other web services , so i want to be sure that my data is correct and will not cause any problems to others.
I want to make validation only in the input of the data , not at the output, hence i will make the validation only once, and also i will be sure that no scripts exist in my db .
EDIT: please check the last comment I added.
Use some Filter to sanitize HTTP request data.
You may go for jsoup, it is very handy:
String unsafe = "<p><a href='http://example.com/' onclick='stealCookies()'>Link</a></p>";
String safe = Jsoup.clean(unsafe, Whitelist.basic());
// now: <p>Link</p>
Ref: http://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer
In short, you can write filter which does proper escaping of User input(map to relevant URL mapping). There could be readily available plugin to do this but I am not aware.
You can refer to this thread XSS prevention in JSP/Servlet web application