API は、呼び出し元と呼び出し先の間のコントラクトです。最も一般的な API の不正使用の形態は、呼び出し元がこのコントラクトの終わりを守らないことによって発生します。たとえば、プログラムが chroot() を呼び出した後に chdir() を呼び出すのに失敗すると、アクティブなルート ディレクトリを安全に変更する方法を指定したコントラクトに違反することになります。ライブラリの悪用のもう 1 つの良い例は、呼び出し先が信頼できる DNS 情報を呼び出し元に返すことを期待することです。この場合、呼び出し元は、呼び出し先の API の動作 (戻り値が認証目的に使用できること) についてある種の仮定をすることで、呼び出し先の API を悪用します。また、相手側から、呼び出し元と呼び出し先のコントラクトを違反することもできます。例えば、コーダーが SecureRandom をサブクラス化し、ランダムではない値を返した場合、コントラクトに違反することになります。
public および final と宣言しています。
@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}
ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();
conn = DriverManager.getConnection(CONNECT_STRING);
--auto-tls フラグを true に設定します。その結果、etcd インスタンスは、クライアントとの TLS 接続に自己署名証明書を使用します。
...
spec:
containers:
- command:
...
- etcd
...
- --auto-tls=true
...
RegisterModel または Details クラス内の属性にバインドします。
public ActionResult Register(RegisterModel model)
{
if (ModelState.IsValid)
{
try
{
return RedirectToAction("Index", "Home");
}
catch (MembershipCreateUserException e)
{
ModelState.AddModelError("", "");
}
}
return View(model);
}
RegisterModel クラスは次のように定義されます。
public class RegisterModel
{
[BindRequired]
[Display(Name = "User name")]
public string UserName { get; set; }
[BindRequired]
[DataType(DataType.Password)]
[Display(Name = "Password")]
public string Password { get; set; }
[DataType(DataType.Password)]
[Display(Name = "Confirm password")]
public string ConfirmPassword { get; set; }
public Details Details { get; set; }
public RegisterModel()
{
Details = new Details();
}
}
Details クラスは次のように定義されます。例 2:
public class Details
{
public bool IsAdmin { get; set; }
...
}
TryUpdateModel() または UpdateModel() を ASP.NET MVC または Web API アプリケーションで使用するとき、モデル バインダーはデフォルトで、自動的にすべての HTTP リクエスト パラメーターをバインドするように試みます。例 3: ASP.NET Web API アプリケーションで、モデル バインダーはデフォルトで、構成済みの JSON または XML シリアライザーまたはデシリアライザーを使用して自動的にすべての HTTP リクエスト パラメーターをバインドするように試みます。デフォルトで、バインダーはすべての可能な属性を HTTP リクエストパラメーターまたは本文からバインドするように試みます。
public ViewResult Register()
{
var model = new RegisterModel();
TryUpdateModel<RegisterModel>(model);
return View("detail", model);
}
例 4: ASP.NET Web フォーム アプリケーションで、
public class ProductsController : ApiController
{
public string SaveProduct([FromBody] Product p)
{
return p.Name;
}
...
}
TryUpdateModel() または UpdateModel() を IValueProvider インターフェイスとともに使用するとき、モデル バインダーは自動的にすべての HTTP リクエスト パラメーターをバインドするように試みます。
Employee emp = new Employee();
TryUpdateModel(emp, new System.Web.ModelBinding.FormValueProvider(ModelBindingExecutionContext));
if (ModelState.IsValid)
{
db.SaveChanges();
}
Employee クラスは次のように定義されます。
public class Employee
{
public Employee()
{
IsAdmin = false;
IsManager = false;
}
public string Name { get; set; }
public string Email { get; set; }
public bool IsManager { get; set; }
public bool IsAdmin { get; set; }
}
Booking クラスの任意の属性にバインドします。
<view-state id="enterBookingDetails" model="booking">
<on-render>
<render fragments="body" />
</on-render>
<transition on="proceed" to="reviewBooking">
</transition>
<transition on="cancel" to="cancel" bind="false" />
</view-state>
Booking クラスは次のように定義されます。
public class Booking implements Serializable {
private Long id;
private User user;
private Hotel hotel;
private Date checkinDate;
private Date checkoutDate;
private String creditCard;
private String creditCardName;
private int creditCardExpiryMonth;
private int creditCardExpiryYear;
private boolean smoking;
private int beds;
private Set<Amenity> amenities;
// Public Getters and Setters
...
}
Order、Customer、および Profile は、Microsoft .NET Entity の永続的なクラスです。
public class Order {
public string ordered { get; set; }
public List<LineItem> LineItems { get; set; }
pubilc virtual Customer Customer { get; set; }
...
}
public class Customer {
public int CustomerId { get; set; }
...
public virtual Profile Profile { get; set; }
...
}
public class Profile {
public int profileId { get; set; }
public string username { get; set; }
public string password { get; set; }
...
}
OrderController は、リクエストを処理する ASP.NET MVC コントローラーのクラスです。
public class OrderController : Controller{
StoreEntities db = new StoreEntities();
...
public String updateOrder(Order order) {
...
db.Orders.Add(order);
db.SaveChanges();
}
}
Order、Customer、および Profile は、Hibernate の永続的なクラスです。
public class Order {
String ordered;
List lineItems;
Customer cust;
...
}
public class Customer {
String customerId;
...
Profile p;
...
}
public class Profile {
String profileId;
String username;
String password;
...
}
OrderController は、リクエストを処理する Spring コントローラのクラスです。
@Controller
public class OrderController {
...
@RequestMapping("/updateOrder")
public String updateOrder(Order order) {
...
session.save(order);
}
}
null を戻すことがある関数の戻り値を確認しないため、NULL ポインタを間接参照する場合があります。Item プロパティによって戻される文字列が null かどうかを、メンバー関数 Equals() をコールする前にチェックしないので、null Dereference の原因になる可能性があります。
string itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {
...
}
...
null 値を間接参照してプログラムが異常終了するのにまかせても同じことです。」null を返すことがある関数の戻り値を確認しないため、NULL ポインタを間接参照する場合があります。malloc() で戻されたポインタを使用する前に、メモリの割り当てが正しく行われたかチェックしていません。
buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);
malloc() のコールが失敗に終わった理由が、req_size の超過によるものか、許容範囲外の同時処理によるものか定かではありません。時間の経過とともに蓄積された Memory Leak によるものかも不明です。エラー処理を怠ると、原因を究明する術はありません。null を返すことがある関数の戻り値を確認しないため、NULL ポインタを間接参照する場合があります。getParameter() によって戻される文字列が null かどうかを、メンバー関数 compareTo() をコールする前にチェックしないので、null Dereference の原因になる可能性があります。例 2:次のコードは、
String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM)) {
...
}
...
null に設定され、それが「常に定義される」という誤った前提でプログラマによって後から間接参照されるシステムプロパティを示します。
System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95") )
System.out.println("Not supported");
null 値を間接参照してプログラムが異常終了するのにまかせても同じことです。」