RSS security risks of financial services

Like the ise2.0 solution, web2.0 has gradually penetrated into the financial service field, adding new value to these services. Analysts use information sources to analyze the nature of phenomena. Trade and banking companies like wells fargo and e * trade are using web2.0 components to develop their next-generation technologies. These components will be used in banking software, trade portals, and other peripheral services. Compared to extracting information from the Internet, the real advantage of the rss component is that it can directly publish information to end users. It is estimated that 95% of the information in the financial industry exists in the form of non-rss. If people can convert the information to the rss format, this advantage of rss will become a key strategic advantage. Wells fargo has implemented such a system and started to get the benefits. However, the security problems of rss itself are very serious for financial services. This article will introduce the popularity of rss security issues and attack vectors.

Rss feedback operations and javascript and html tags

The rss stream obtains the structure from the database or user input. Rss streams can obtain information from third-party sources such as news sites and blogs. Financial Services integrate the information for end users so that the information appears in the browser together with other sensitive information. If rss feedback is from untrusted sources, they are likely to be injected with javascript or other html tags. These malicious tags are likely to attack browsers. Before forwarding any information from end users, the financial system must use reliable filtering tables for filtering, or they must filter specific character sets. People are increasingly using rss, which puts users in the financial field at risk. To defend against such threats, people should validate rss Input and Output in financial applications.

Cross-site scripting (xss/css) and rss feedback

Rss Script Injection allows hackers to use xss to successfully launch rss attacks. After javascript-injected rss is successfully injected to end users in the financial system, it may cause attacks such as script rss feedback or href attacks with "onclick. Many attacks are written in xss. Attackers can use them to hijack sessions or run keylogger in sessions. All these attacks may compromise the security of the financial system. To cope with such threats, people must "filter" character sets before they reach end customers ". The browser does not have its own filter function. For security reasons, we need to support the filter function at the application layer. People must be especially careful when conducting cross-origin conversations or cross-site rss access.

Csrf and rss feedback

Forgery of Cross-Site requests is another attack that can be carried out through rss feedback. If a feedback is injected with html tags or other tags that allow cross-origin dialogs, these dialogs replay cookies and cause csrf attacks. Csrf attacks increase the chance of financial applications with vulnerabilities being attacked. Because the target is locked and the range is determined, the chance of successful attackers is also increased.

Assume that the rss reader component is running on the financial portal of a bank operation application. This component contains a set of applications for trading and other services on different domains. In addition, a program in these applications is very vulnerable to csrf attacks, and it also shares the "single sign on" method through cookies or common database access. In this case, attackers can launch a wide range of csrf attacks to achieve the best attack effect-forging an rss request. Once an attacker can identify an end user, the locked rss feed reader will become a helper using this attack vector.

SQL Injection for rss feedback operations

SQL injection is usually a synchronous attack vector for network applications. In SQL injection attacks, attackers send special loads and observe the response. If the response is consistent with the signal of successful SQL injection, it can initiate further attacks.

Now, all new applications provide rss feedback tailored to user requirements. For example, the content of rss feedback may be 10 latest reports or statements over a period of time. All these parameters are provided by end users and will be generated by rss feedback programs for SQL queries. If the rss feedback generator program is vulnerable to SQL injection attacks, attackers can forge an SQL load and send it to rss feedback, causing non-synchronous SQL injection attacks. Once the feedback generate a program to run a user's request and create a custom rss feedback for the client, this attack also runs successfully, and attackers can access user information without authorization. In order to prevent such attacks, people must review the Generated Routes of rss feedback properly. This attack vector is not synchronous, so it is difficult to find it using black box detection.

Rss feedback verification and authorization

In the http format, rss does not have a header authentication mechanism. Therefore, the rss feedback transmission must obtain authentication permission from the network server or application layer. Because rss is a static xml feedback, it is difficult to balance it From the security perspective. People can retrieve rss feedback that has been open without any authentication. If an application uses hidden parameters or security code to provide rss feedback, people can guess or forcibly crack these parameters based on a small amount of available information. A legitimate user of a bank application knows the url to access his custom feedback, but he may try different url combinations to access feedback from other users. If the rss feedback method configured at the application layer meets the conditions, the above situations may occur. Generally, people can forcibly crack the rss feedback that is locked with basic/ntlm authentication. When dealing with important financial information, people must use the powerful Application Layer Feedback that integrates the session review function. Another security issue to be addressed is that sensitive information such as passwords will be sent to online rss readers. Therefore, when using financial services, "where to read your rss feedback" is crucial.

Rss encryption Problems

At the xml level, people cannot encrypt rss. Unlike network services, there are no ready-made rss security standards. Atom has xml encryption and signature solutions, but these technologies are not widely used. To ensure the security of rss information during transmission, people need to use it on https. If there is a custom encryption mechanism, people need to pass the "key" information to other places, either through a browser or a third-party application. There are risks in doing so. If you want higher security, people should perform rss encryption Point to Point. Otherwise, rss information may be peeked during transmission, resulting in unnecessary security problems. Therefore, before deciding on configuration or receipt, people should ensure that the target rss feedback is in the form of http/https. Https is required when we use financial services.

Rss widget

Javascript widgets are very popular, and are also seen in rss feedback. It is easy for people to configure third-party rss window widgets and integrate them into network applications. To reduce security risks, people should check the source code of rss windows used in financial applications. Attackers may also use these widgets on personal webpages or computers-insecure Widgets may compromise user session security.

Conclusion

People are increasingly using rss, so it is connected to important financial databases. It has two threats: on the server side, attackers can use custom feedback routing lines to launch attacks. On the client side, attackers can intercept sessions or execute malicious code. Although rss is highly flexible and can publish data to customers, its security costs are extremely high. End users can read the feedback. It is up to end users to apply the feedback. This makes it difficult for both parties to balance and ensure low security. The feedback may be received by software running in a vulnerable environment. In this way, the client is very vulnerable to attacks. For financial services, the most important thing is to control the receipt of rss feedback, and to effectively isolate rss content.

(End)