Principle:
Logic vulnerability refers to that some logic branches cannot be handled normally or handle error problems due to loose program logic or too complex program design, which may lead the attacker to carry out some operations through such problems.
The attack deviated from the expected user behavior.
There are two key points in mining logical vulnerabilities: business process and tampering of HTTP/HTTPS requests.
1, Ultra vires
1.1 horizontal ultra vires
For example, when http://www.xxx.com It provides the function for users to modify data when accessing http:///www.xxx.com/userinfo.action?id=1 Display your own data and edit it. The source code of Userinfo is as follows:
public String execute(){
int id = this.user.getUserId();
this.user = new UserProxy.findUserById(id);
return SUCCESS;
}
This code is useless to verify the ID parameter. It directly receives the ID parameter sent by the user and queries the information according to the user ID.
At this point, we change the ID value, http:///www.xxx.com/userinfo.action?id=3 At this time, the program will return the user information when id = 3, which is horizontal ultra vires.
Horizontal ultra vires mainly refers to the ultra vires operation of data between users with the same authority.
Examples of horizontal ultra vires:
Take any password modification as an example:
public String execute(){
int id = Integer.parseInt(request.getParammeter("userId"));
String password = request.getParameter("password");
String password2 = request.getParameter("password2");
if(!("".equals(password)||"".equals(password2))){
return ERROE;
}
if(!password.equals(password2)){
return ERROR;
}
User u = new UserBiz().findUserById(id); //Get User specific object according to ID
u.setPassword(password);
boolean flag = new UserBiz().saveOrUpdate(u); //Update Object
if(flag){
return SUCCESS;
}else{
return ERROR;
}
}
This code has a hidden logic vulnerability, which is arbitrary password modification. Suppose there are two users, one is Admin, and the UserId is 1 When another user is a Guest, the UserId is 2. When the Guest changes the password, it intercepts the HTTP request. The HTTP request is as follows:
POST /user/UpDateUser.action HTTP/1.1 HOST:www.xxx.com Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent:Mozilla/5.0 Referer:http://www.xxx.com/user/userinfo.action ...... id=2&password=myuser123&password2=myusrer123
In this case, ID=2 The password is myuser123. When Guest changes the user ID parameter to 1, the password of Admin user will be changed to myuser123 The program will query all i southwest and west of the Admi user according to the ID. Then change the password of the Admin user. However, adding an original password verification can prevent such things from happening.
1.2. Vertical ultra vires
Vertical ultra vires are ultra vires operations between users with different permissions or users with different roles.
Vertical ultra vires are divided into upward ultra vires to high authority operations and downward ultra vires to low Authority operations.
2, Password recovery logic vulnerability
Common password retrieval methods: email retrieval, security problem retrieval, mobile phone number retrieval, original password retrieval, etc. In any way, when retrieving the password, in addition to your own user password, if you can also retrieve the passwords of other users, there is a password retrieval vulnerability.
3, Payment logic vulnerability
The focus of testing payment logic vulnerabilities lies in the analysis of HTTP requests and business processes.
When testing the vulnerability of payment logic, there are also several emphases. The parameters submitted by users: such as purchase quantity, commodity price, discount, freight, rolling page of commodity information, jump to payment interface and other parameters.
1. Product quantity is negative
When purchasing a commodity, the algorithm is generally: purchase quantity X purchase unit price = payment amount, but if the purchase quantity is negative, such as - 5, the payment amount will be negative, as shown in the following code:
public class order extends HttpServlet{
public void doGet(HttpServletRequest,HttpServletResponse response)
throws ServletException,IOException{
this.doPost(request,reponse);
}
publicc void doPost(httpServletRequest,HttpServletResponse response)
throws ServletException,IOException{
User u=(User)request.getSession().getAttribute("User");
u=new userBiz().findUserById(u.getID());
int commodityId= Integer.parseInt(request.getParameter("commodityID"));
int number=Integer.parseInt(request.getParameter("number"));
commodity com = new CommodityBiz().findCommodityById(commodityID); //Query commodity information according to ID
if(comm.getNumber()<number){
reuqest.setAttribute("messafe","The quantity of goods is insufficient and cannot be purchased")；
request.getRequestDispatcher("/user/userinfo.do").forword(request,response);
}
double appprice = number*comm.getPrice(); //Query total price
if(u.getMoney()<allprice){
request.seetAttribute("message","Your amount is insufficient. Please recharge it in time. It's not enough"+(allprice-user.getMoney())+"Gold coins")；
request.getRequestDispatcher("/user/userinfo.do").forward(request,response);
}
u.setMoney(u.getMoney()-allprice); //Remove the user's gold coins
u.getCommodity().add(commodityID);
UserDao userDao = new UserBiz();
boolean flag=userDao.saveOrUpdate(u); //Update user gold coins
comm.setNumber(comm.getNumber()-number);
CommodityDao comDao=new CommodityBiz();
boolean cflag=comDao.saveOrUpdate(comm);
if(flag&& cflag){
request.setAttribute("message","Purchase success,The balance is:"+u.getMoney());
request.setAttribute("User",u);
request.setAttribute("Commodity",comm);
request.getRequestDispatcher("/user/userinfo.do").forward(request,response);
}else{
request.setAttribute("message","Purchase failed with exception")；
requesu.getRequestDispatcher("/user/userinfo.do").forward(request,response);
}
}
}
Execution process of the above code:
1. Get the User object from the session, that is, the current User information.
2. Query the latest information of the current User in the database according to the User ID.
3. Get the ID of the commodity, and query the price, quantity and other information according to the commodity ID.
4. Judge the quantity of goods. If the user's purchase quantity is greater than the inventory quantity, jump to the page and end shopping.
5. Calculate the total price according to the quantity.
6. Judge whether the user's Money and commodity quantity are reset, and then save. If they are successful, proceed to the next step. Otherwise, the page jumps to end shopping.
7. Reset the user's Money and the quantity of goods, and then save them. If they are successful, proceed to the next step. Otherwise, the page will jump to end the shopping.
8. Put the latest user information and product information into the Session.
This code is a common purchase process, in which the security risk is. Suppose the user Money=100, the commodity price = 30, and the quantity = 20. After a user purchases a commodity, Money=100-30=70 and the quantity is 19. This is a normal purchase process.
If the purchase quantity is - 3 and then purchased, when calculating the price, the servlet does not verify the negative number, but directly calculates: 30X (- 3) = - 90, then the current number of goods is - 90 yuan. Next, judge whether the user amount is sufficient, and then proceed to the next step. u.setMoney(u.getMoney()-allprice) means to reset the user's Money, 100 - (- 90) = 190, but the balance becomes more.
4, Malicious attack on specified account
In some websites with high security, the account will be locked after entering the wrong password three times, which is a typical problem of unable to log in due to too many wrong password input times.
Under normal circumstances, the number of password errors entered by normal users will not exceed three times. If more than three times, it may be that the attacker is trying to crack the password.
If the attacker just wants to lock the account indiscriminately, this behavior of harming others and not benefiting himself happens to be a malicious attack on the account.
5, Defense
Logic vulnerabilities are basically caused by attackers cutting into the original business process to access data with unexpected requests or operations of developers. Therefore, when defending against logic vulnerabilities, we must improve from the beginning of business code design:
1. Ensure that developers and testers understand the application service;
2. Avoid making implicit assumptions about user behavior or the behavior of other parts of the application;
3. Ensure that any input value is reasonable and respond accordingly to any value entered by the user;
4. Maintain clear design documents and data flows for all transactions and workflows, and pay attention to any assumptions made at each stage.