I am receiving a Trust Boundary Violation from Veracode.
My code is
userName= req.getParameter(Constant.USERNAME);
session.setAttribute(Constant.USERNAME, userName); //At this line i am getting Trust Boundry Violation flaw.
How can I validate userName to avoid a trust boundary violation flaw?
Simply use a regular expression to validate the userName according to the rules your usernames follow:
if(userName.matches("[0-9a-zA-Z_]+")
session.setAttribute(Constant.USERNAME, userName);
VeraCode will require you to file a mitigation with them. They will schedule a consultation with you and there you can show them the code fix(s) implemented and they will then mark the mitigation approved.
Yes, I know this is late but others may trip through and it needs to be pointed out.
Trust boundary violation happens when user input is set into session. Using this flaw attacker can set any other username in to session and can cause impersonation. Where ever username is accessed is code from session(session.getattribute) will give attacker privileges of that user.
Mitigation: before setting user input into session, make sure that username that is set in to session is of authenticated user.
Validate your data using ESAPI.validator().getValidInput(...) and then set the value into a session object.
Related
I am building a web app which runs react on the front end and Java/Spring on the back end.
I am using a RESTful API to communicate with my client (client will communicate with an external API too).
I am facing a problem. When a user registers, I want to send an email verification code. My question is about practice.
Is it ok to send an email with a verification code, store the code in the database and then check if the code is correct?
Or is it better to create some static bean which would hold the code for a while and then check if it's correct?
I am not sure which is better in terms of back-end logic.
I appreciate all help.
It's a very common practice to store this in the DB. Just make sure to cleanup the expired tokens once in a while (maybe on timer, maybe when inserting new ones).
You can also store the tokens in an in-memory cache (EhCahe comes to mind) and set the expiration time accordingly, but this way you lose the cache if the application shuts down. Yes, you can make the cache persistent, but why not go the DB route then?
With that said, think about not storing the token anywhere and instead send the link with the email as an URL parameter and a salted hash as an additional parameter. Once the link is clicked, you can check if the hash matches and if it does, the email parameter wasn't tempered with, so you can mark it as validated. Maybe not Pentagon-level secure, but probably enough for email validation and makes everything easier.
In pseudo-code:
public String hash(String email) {
MessageDigest digester = MessageDigest.getInstance("SHA-256");
digester.update(email.getBytes(StandardCharsets.UTF_8)));
digester.update("RanDOmComplCatEdSalt647826583745".getBytes(StandardCharsets.UTF_8));
return Base64.getEncoder().encodeToString(digester.digest());
}
String email = "dude#example.com";
sendEmailWithLink("/verify?email=" + email + "&hash=" + hash(email));
On the way in, you just do the exact same thing to calculate and check if the hash matched:
String email = httpRequest.getParameter("email");
String receivedHash = httpRequest.getParameter("hash");
if (hash(email).equals(receivedHash)) {
//the user didn't do anything funny, mark email as valid
}
Or, taking this idea further but with more security, you can generate something like a JWT that contains the email and is properly encrypted.
I'm using Java - Apache Directory Client API for accessing Apache DS Ldap Server using ldapConnectionTemplate.
I'm trying to implement a feature which allows the user to reset/change the password. My password policy has a password history attribute value of 5. So user will not be able to use any of the previous 5 passwords.
When I'm using the modifyPassword method for changing the password(i.e. as a user by passing current and new password), it respects the password history policy. i.e I'm not allowed to use any of the previous 5 passwords and getting password exception as expected. But when using the reset option(i.e. - only new password), it does not honor the password policy. It accepts any value(including current one) and updates the password.
How to make the reset password scenario honor the password history policy? Any ideas, suggestions and solutions are welcome.
I don't believe the behaviour you desire is specified anywhere.
The idea of a 'reset' in the sense you mean is that the admin sets it to something known, tells the user what it is, and the pwdReset attribute is set to TRUE so that the user is forced to immediately change it on next login - which you have to enforce yourself by using the PasswordPolicy request control and inspecting any PasswordPolicyResponse for CHANGE_AFTER_RESET.
There's no particular reason why the admin should be constrained by the pwdHistory, and anyway the user is going to be forced to change the password again anyway, at which time he will be constrained by pwdHistory.
I'm able to create the user in LDAP but its creating in disabled mode. When try to enable and give the password as Never Expire got this error. LDAP: error code 53 - 0000052D: SvcErr: DSID-031A11E5, problem 5003
This error code is very specific to Active Directory and indicates an "Unwilling to Perform". You can only set a password if the connection is secured by a certificate.
The hex value 0000052D of your diagnostic message relates to a system error code. Specifically:
ERROR_PASSWORD_RESTRICTION
1325 (0x52D)
Unable to update the password. The value provided for the new password
does not meet the length, complexity, or history requirements of the domain.
Either the password you are trying to set for the user account does not meet the password policy requirements or you are not encoding it properly (unicodePwd must be UTF-16LE).
I use ppolicy overlay and enabled ppolicy_use_lockout to separate between invalid password and locked accounts.
database bdb
suffix "dc=openiam,dc=com"
rootdn "cn=Manager,dc=openiam,dc=com"
rootpw "{SSHA}2ttRoo/t5HuMT2nPxtI6goVUML5R2H9h"
# PPolicy Configuration
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=openiam,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext
I tried to lock user account by entering wrong password couple of times (pwdMaxFailure)
The user is being locked but when I try to login again I still get the same error:
Invalid credentials (49)
Any idea why i am not getting diffrent error to disticnt between the cases?
thanks,
ray.
you should add -e ppolicy when use ldapwhoami to get more information like (Password expired, 3 grace logins remain)
You will get a password policy response control that tells you the error, if you request it with the corresponding request control.
Note that it's a bad idea to let this show through to the user, for the reasons stated in the password policy draft, section 12. Basically you would be leaking information to an attacker.
Note also that this technique also applies to my answer to your previous question which I have now corrected.
I am creating a java application that able to login to LDAP server with OpenDJ Client SDK, but I only has Domain Name, User Name (also known as SAMAccountName), and Password. If you don't know domain login, see this image:
You enter the user name field in format: DOMAIN_NAME\USER_NAME instead of just plain USER_NAME. Example of Domain Name is: corp.fabrikam.com.
Now I need to know how to convert Domain Name to Distinguished Name (DN)? Because OpenDJ requires Distinguished Name to connect to LDAP.
For example: Distinguished Name from corp.fabrikam.com is: dc=corp, dc=fabrikam, dc=com.
It seems I just need to split it by ".", but I heard there is thing called Disjoint Domain:
http://technet.microsoft.com/en-us/library/cc731125%28v=ws.10%29.aspx
So splitting trick might not reliable here.
Also, user in LDAP can be under an Organizational Unit (OU). Let's say user john is belong to manager OU, so the full user DN of john would become like this:
uid=john, ou=manager, dc=corp, dc=fabrikam, dc=com
You should always refer to the RootDSE entry of the ldap server to get information about the environment you are connecting to. The RootDSE entry is readable by anyone upon an anonymous bind ( or a particular user, it does not really matter, as long as you are bound ). It contains a lot of interesting stuff, the one you are looking for is defaultNamingContext.
Once bound, perform an ldap read operation on the DN of an empty string: ''. If the framework of your choice provides some API to read the rootDSE, try to use that. It might be much more simple.
This might help you to get a kickstart:
http://opendj.forgerock.org/opendj-ldap-sdk/apidocs/index.html
I did not find any mention of the defaultNamingContext on the opendj documentation pages, but you might just get the information you are looking for via getNamingContexts() method.
Note that rootDSE is an ldap feature, it's not implementation-specific.