SSLstrip future--https Front End hijacking (1)

0x00 in a previously described traffic hijacking article, the introduction of a "https downgrade down" scenario--Replaces all HTTPS hyperlinks in the page with HTTP versions, allowing users to always communicate in clear text. See this, perhaps everyone will think of a classic man-in-the-middle attack tool--sslstrip, through which it does achieve this effect. Today, however, it is a completely different idea, a more effective, more advanced solution--https front-end hijacking. 0x01 back-end defects in the past, traffic hijacking basically through the backend to achieve, SSLstrip is a typical example. Similar to other intermediary tools, the implementation of the pure backend can only manipulate the most primitive flow data, which seriously hinders the development to a higher level, facing many difficult problems. What about dynamic elements? How do I handle packet fragmentation? Can the performance consumption be reduced?...... Dynamic elements in the early days of the Web, sslstrip such tools still have a lot to do. At that time the Web pages are mainly static, simple structure and clear. Replacement on the flow, fully competent. Today's web pages, however, are increasingly complex, with more and more scripts. If only from the flow of the start, obviously powerless. Varprotocol= ' https '; document.write (' <ahref= "' +protocol+ '://www.alipay.com/" >Login</a> "); even a very simple dynamic element, the back end has no power to parry. The principle of fragment processing and block transmission we all understand. For larger data, the breath is not complete. The client receives each block of data in turn before it can be merged into a complete Web page. 498) this.width=498 ' OnMouseWheel = ' javascript:return big (This) ' border= ' 0 "alt=" SSLstrip's future--https front end hijacking "width=" 521 " height= "205" src= "http://s3.51cto.com/wyfs02/M00/4D/AA/wKiom1RW6ZWT-0h1AAAswwGQRzU074.png"/> Because each received is a fragmented fragment, This brings a lot of trouble to the replacement of the chain. Adding many pages is not a standard UTF-8 code, so it is even more difficult. In order to be able to proceed smoothly, the intermediary usually collects the data first, waits until the page receives the complete, only then starts the substitution. 498) this.width=498 ' OnMouseWheel = ' javascript:return big (This) ' style= ' width:491px; height:132px "border=" 0 "alt=" SSLstrip future--https Front-End Hijacking "width=" 823 "height=" "src=" http://s7.51cto.com/wyfs02/M01/ 4d/a9/wkiol1rw6gga3mugaabcnseanxs927.png "/> If the data is likened to a stream, the agent, like a dam, intercepts a steady stream of water that is not released until it is full." So people downstream need to endure a long drought to wait for water. Performance consumption because HTML is compatible with many legacy specifications, replacing work is not easy. A variety of complex regular expressions, consuming a lot of CPU resources. Although the user finally clicked on only one or two of them, the middle man did not know which one was going to be, so the entire page still needed to be parsed. It's a sad thing to say. 1 2 3 4 5 6 next page >> view full text navigation 1th page: Defect on the back end page 2nd: Front edge 3rd: More interception 4th page: Back end match 5th page: Precautionary measures 6th page: attack Demo original: SSLstrip future--https Front hijacking (1) Back to net Contact Security Home