[悬赏]API中的前5名漏洞 (已翻译100%)

【已悬赏】 赏金: 2元

A vulnerability in the context of software applications is a violation of the defined security policies. Modern web apps are centered on the idea of keeping the workflow logic in the client side and its interaction with the server using APIs (application programming interface). Developers try to make the APIs as stateless as possible, in accordance with the REST principles. This, however, adds a new attack surface. Poorly designed APIs are often subjected to attacks. Here are top 5 API vulnerabilities that you need to take care of in 2017:

A vulnerability in the context of software applications is a violation of the defined <a href="https://datafloq.com/read/?page=1&cat=38#%3Futm=internal">security</a> policies. Modern web apps are centered on the idea of keeping the workflow logic in the client side and its interaction with the server using <a href="https://en.wikipedia.org/wiki/Application_programming_interface">APIs</a> (application programming interface). Developers try to make the APIs as stateless as possible, in accordance with the <a href="https://en.wikipedia.org/wiki/Representational_state_transfer">REST principles</a>. This, however, adds a new attack surface. Poorly designed APIs are often subjected to attacks. Here are top 5 API vulnerabilities that you need to take care of in 2017:

【已悬赏】 赏金: 2元

1.DDoS

Poorly designed APIs are often a target of DDoS attacks. Often developers do not put rate limits on the APIs, or block malicious requests. Sometimes API endpoints have complex logic behind them which is computationally heavy to run, like authentication logic that requires a hashing algorithm like Bcrpyt. When an attacker finds out such an endpoint, they spam it with requests taking the whole system down. Such endpoints should be served independently from the main APIs so that limited functionality is affected in an attack. Rate limits should also be applied differently to different APIs; authenticated users may raise their rate limits though.

<h2> 1.DDoS </h2> <p> <a href="https://github.com/Microsoft/api-guidelines?utm_source=datafloq&utm_medium=ref&utm_campaign=datafloq" target="_blank">Poorly designed APIs</a> are often a target of <a href="https://en.wikipedia.org/wiki/Denial-of-service_attack">DDoS attacks</a>. Often developers do not put rate limits on the APIs, or block malicious requests. Sometimes API endpoints have complex logic behind them which is computationally heavy to run, like authentication logic that requires a hashing <a href="https://datafloq.com/read/12-algorithms-every-data-scientist-should-know/2024?utm=internal">algorithm</a> like Bcrpyt. When an attacker finds out such an endpoint, they spam it with requests taking the whole system down. Such endpoints should be served independently from the main APIs so that limited functionality is affected in an attack. <a href="http://stackoverflow.com/questions/8775079/how-to-rate-limit-an-api">Rate limits</a> should also be applied differently to different APIs; authenticated users may raise their rate limits though. </p>

【已悬赏】 赏金: 2元

2. Enumerated Resources

APIs that have enumerated resources are a goldmine for attackers. This faulty design pattern is one of the most commonly seen in APIs. Recently McDonalds India was found to have been leaking user information through an unauthenticated public API. That is very bad in itself but what made the matter worse was that the user ids were enumerable - which means that an attacker does not have to guess the user ids, they can just iterate over a range and get all the data. Enumerated badness is widely known as one of the most common and dumbest design flaws.

<h2> 2. Enumerated Resources </h2> <p> APIs that have enumerated resources are a goldmine for attackers. This faulty design pattern is one of the most commonly seen in APIs. Recently McDonalds India was <a href="https://datafloq.com/found/?utm=internal">found</a> to have been <a href="https://hackernoon.com/mcdonalds-india-is-leaking-2-2-million-users-data-d5758b2eb3f8">leaking user information</a> through an unauthenticated public API. That is very bad in itself but what made the matter worse was that the user ids were enumerable - which means that an attacker does not have to guess the user ids, they can just iterate over a range and get all the data. <a href="https://www.cs.clemson.edu/course/cpsc420/material/Papers/The%20Six%20Dumbest%20Ideas%20in%20Computer%20Security.pdf?utm_source=datafloq&utm_medium=ref&utm_campaign=datafloq" target="_blank">Enumerated badness</a> is widely known as one of the most common and dumbest design flaws. </p>

【已悬赏】 赏金: 3元

3. Sharing resources via unsigned URLs

Often an API returns links to hypermedia resources like images/audios/videos. These resources can be then be consumed by the user in any way they like. For example, a direct to link to a video can either be played in the browser, or in a multimedia player like VLC. Such resources, however, are prone to hotlinking - which causes several problems to the provider: none or poor analytics, strains on resources, no way for branding, no way to return to the original content provider. It is, therefore, necessary that the shared resources URLs are unique and identifiable. A signed URL can be used to implement policies like rate limiting, automatic expiration, and scoped sharing. Signed URLs are used by all the major websites, cloud storage providers and virtual data room providers. If you want to use signed resource sharing in your applications, both Amazon AWS and Google Cloud Platform provide access to automated URL signing.

<h2> 3. Sharing resources via unsigned URLs </h2> <p> Often an API returns links to hypermedia resources like images/audios/videos. These resources can be then be consumed by the user in any way they like. For example, a direct to link to a video can either be played in the browser, or in a multimedia player like VLC. Such resources, however, are prone to <a href="https://simple.wikipedia.org/wiki/Hotlinking">hotlinking</a> - which causes several problems to the provider: none or poor <a href="https://datafloq.com/read/descriptive-predictive-prescriptive-analytics/151?utm=internal">analytics</a>, strains on resources, no way for branding, no way to return to the original content provider. It is, therefore, necessary that the shared resources URLs are unique and identifiable. A signed URL can be used to implement policies like rate limiting, automatic expiration, and scoped sharing. Signed URLs are used by all the major websites, <a href="https://datafloq.com/read/?page=1&cat=39#%3Futm=internal">cloud</a> storage providers and <a href="http://www.securedocs.com/blog/virtual-data-room-information">virtual data room</a> providers. If you want to use signed resource sharing in your applications, both <a href="http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html">Amazon AWS</a> and <a href="https://cloud.google.com/storage/docs/access-control/create-signed-urls-program">Google Cloud Platform</a> provide access to automated URL signing. </p>

【已悬赏】 赏金: 3元

4. Vulnerabilities in 3rd party libraries

Modern workflow in any organization makes use of a lot of 3rd party libraries, often under open source or free software licenses. The benefit is that developers are not required to reinvent the wheel and are also not concerned about updating that library to add more features or fix bugs themselves (not obligatory, but they should!). This introduces a new attack surface because of an external element and the developers relegating the security fixes too. JWT authentication is the most commonly used form of authentication in modern APIs. The benefit is that it is stateless by design and fits in very well with the REST principles. Many popular JWT libraries were found to have critical vulnerabilities in 2015, putting developers around the world in a frantic race against attackers to patch their APIs. The only solution is to be vigilant and auditing the source of each external dependency - for your own security and also for the greater good.

<h2> 4. Vulnerabilities in 3rd party libraries </h2> <p> Modern workflow in any organization makes use of a lot of 3rd party libraries, often under open source or free software licenses. The benefit is that developers are not required to reinvent the wheel and are also not concerned about updating that library to add more features or fix bugs themselves (not obligatory, but they should!). This introduces a new attack surface because of an external element and the developers relegating the <a href="https://datafloq.com/read/?page=1&cat=38#%3Futm=internal">security</a> fixes too. <a href="https://en.wikipedia.org/wiki/JSON_Web_Token?utm_source=datafloq&utm_medium=ref&utm_campaign=datafloq" target="_blank">JWT authentication</a> is the most commonly used form of authentication in modern APIs. The benefit is that it is stateless by design and fits in very well with the REST principles. Many popular JWT libraries were found to have <a href="https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/?utm_source=datafloq&utm_medium=ref&utm_campaign=datafloq" target="_blank">critical vulnerabilities</a> in 2015, putting developers around the world in a frantic race against attackers to patch their APIs. The only solution is to be vigilant and auditing the source of each external dependency - for your own security and also for the greater good. </p>

【已悬赏】 赏金: 1元

5. Improper use of CORS

While using CORS in itself is not bad, in fact it is necessary when using resources from another origin via the client (browser) directly, it is often riddled with improper implementations causing unintentional side-effects. The “Access-Control-Allow-Origin” header is often set to allow all origins by developers whereas they only intended it to be used by their own website. For public APIs it is perfectly fine but otherwise it can be a cause of problems due to hotlinking.

<h2> 5. Improper use of CORS </h2> <p> While using <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS?utm_source=datafloq&utm_medium=ref&utm_campaign=datafloq" target="_blank">CORS</a> in itself is not bad, in fact it is necessary when using resources from another origin via the client (browser) directly, it is often riddled with improper implementations causing unintentional side-effects. The “Access-Control-Allow-Origin” header is often set to allow all origins by developers whereas they only intended it to be used by their own website. For public APIs it is perfectly fine but otherwise it can be a cause of problems due to hotlinking. </p>