在辩论的背景下,出现了一个问题:当客户端知道所有端点名称时,应考虑哪些安全措施?该场景涉及到客户端知道服务在服务器端公开的特定位置或地址。
e4eetjau1#
真的没有什么不同,然后有人知道一个网站的网址?只要这些API不使用数据库PK id,或者如果在这种情况下,API将基于用户登录的数据限制到给定的数据库PK。所以,不,这不应该是一个问题。一般来说,我不会向客户端网页(JavaScript)公开数据库PK id,也不允许API调用。然而,在允许传递数据库PK id的情况下,必须强制执行基于用户登录的限制(服务器端),否则我可以传递属于其他人的信用卡号码并获取其余额。然而,如所指出的,对于允许或使用或向客户端侧网页暴露例如数据库PK_id的一般网页的相同基本限制必须被进一步测试和过滤。那么,即使是页面上一个简单的文本框,提示输入发票号码?那么,发票余额或发票号查询仍然必须根据用户登录来限制数据。因此,将非常相同的基本概念应用于Web API,并且就像在简单数据输入页面上用于数据查询的任何简单数据输入一样?该用户输入必须是SQL注入安全的,并且通常还必须根据用户的登录对返回的数据集进行过滤。因此,无论是一个简单的网页,还是一个简单的API调用,规则都是非常相同的。例如,在一个简单的网页上,如果用户从一个表(或gridview,或其他)中选择一个值,那么在这种情况下,我不会公开数据库PK,我将只将行索引选择传递给服务器端代码。然而,使用Web API,则该表的数据键列表不太可能被持久化或可用。因此,这是一个简单的文本框,提示输入一些“id”,还是一个API调用?同样的规则也适用。因此,接受输入的基本网页或API调用的安全风险应该不会增加或减少。因此,特定网页或特定web API的知识不应该重要。另一方面,如果这些API可以执行原始数据库函数,那么你就有一个巨大的安全问题。然而,该安全问题不是一些API或一些网页的结果,而是设计的结果,确保这种用户提供的输入是有效的,并且也不是危险的,也不能允许人们获取或抓取不属于所讨论的当前用户的数据。
1条答案
按热度按时间e4eetjau1#
真的没有什么不同,然后有人知道一个网站的网址?
只要这些API不使用数据库PK id,或者如果在这种情况下,API将基于用户登录的数据限制到给定的数据库PK。
所以,不,这不应该是一个问题。
一般来说,我不会向客户端网页(JavaScript)公开数据库PK id,也不允许API调用。
然而,在允许传递数据库PK id的情况下,必须强制执行基于用户登录的限制(服务器端),否则我可以传递属于其他人的信用卡号码并获取其余额。
然而,如所指出的,对于允许或使用或向客户端侧网页暴露例如数据库PK_id的一般网页的相同基本限制必须被进一步测试和过滤。
那么,即使是页面上一个简单的文本框,提示输入发票号码?那么,发票余额或发票号查询仍然必须根据用户登录来限制数据。
因此,将非常相同的基本概念应用于Web API,并且就像在简单数据输入页面上用于数据查询的任何简单数据输入一样?
该用户输入必须是SQL注入安全的,并且通常还必须根据用户的登录对返回的数据集进行过滤。
因此,无论是一个简单的网页,还是一个简单的API调用,规则都是非常相同的。
例如,在一个简单的网页上,如果用户从一个表(或gridview,或其他)中选择一个值,那么在这种情况下,我不会公开数据库PK,我将只将行索引选择传递给服务器端代码。然而,使用Web API,则该表的数据键列表不太可能被持久化或可用。因此,这是一个简单的文本框,提示输入一些“id”,还是一个API调用?同样的规则也适用。
因此,接受输入的基本网页或API调用的安全风险应该不会增加或减少。
因此,特定网页或特定web API的知识不应该重要。
另一方面,如果这些API可以执行原始数据库函数,那么你就有一个巨大的安全问题。然而,该安全问题不是一些API或一些网页的结果,而是设计的结果,确保这种用户提供的输入是有效的,并且也不是危险的,也不能允许人们获取或抓取不属于所讨论的当前用户的数据。